[MÚSICA]
Bienvenidos, oyentes, a otro episodio deITIL 4 Sin
Filtros, Elevando el ITSM.
Hoy vamos a hablar de esos momentos en los que todo falla
y hay que correr.
Oh, sí.
De esos días donde el sistema se cae, el teléfono no para.
Y tú solo piensas, ¿quién me manda a trabajar en esto?
Hola, Alex.
Hola, Julián.
El tema es gestión de incidentes,
pero tranquilos que no lo vamos a complicar.
Nos acompañan dos invitados de lujo que sí saben cómo manejar
el caos sin perder la calma, Raquel y Marcos.
Así que quédate con nosotros que esto promete.
[MÚSICA]
¿Nunca les ha pasado esa sensación de pánico cuando
justo vas a pagar online o a enviar ese trabajo crucial y
zas, la aplicación o la web se quedan colgadas?
¿Ese momento de querer lanzar el ordenador por la ventana?
Uf, total.
O la plataforma de streaming que falla justo cuando empieza el
partido o tu serie favorita.
Un drama moderno, vamos.
Pues precisamente de cómo evitar o, bueno,
minimizar esos dramas, va nuestro análisis de hoy.
Vamos a explorar cómo las organizaciones intentan
restaurar la normalidad lo más rápido posible tras una
interrupción inesperada.
Sí, nos metemos de lleno en la gestión de incidentes, ¿eh?
Usando como guía la práctica ITIL4 y también un documento
bastante interesante sobre una técnica llamada swarming.
Nuestra misión hoy, destilar lo esencial sobre cómo manejar
estas interrupciones de forma eficaz, de forma ágil,
para que todo vuelva a funcionar como debería.
A ver, empecemos por lo básico.
¿Qué es exactamente un incidente en este contexto?
Buena pregunta.
Según ITIL, un incidente es cualquier interrupción no
planificada de un servicio o una reducción en su calidad.
Ojo, no tiene que ser un apagón total,
una lentitud exasperante o que falle una función concreta
también cuenta, ¿eh?
Entendido.
O sea, no solo cuando algo se rompe del todo.
Y el objetivo es, imagino, arreglarlo rápido para
minimizar el daño, ¿no?
Que los usuarios estén contentos y la empresa pues
mantenga su reputación.
Exactamente.
Se trata de restaurar la operación normal del servicio
cuanto antes.
Y esa operación normal, pues, se define normalmente en los
acuerdos de nivel de servicio, los SLA,
o en documentos técnicos internos.
Un detalle curioso es que a veces implica arreglar algo que
el usuario ni nota, como, no sé,
un servidor que empieza a sobrecalentarse,
pero aún no afecta el rendimiento visible.
Eso es interesante, actuar antes de que el problema escale.
Para gestionar esto de forma eficiente,
he oído hablar de los modelos de incidente.
¿Suenan a plantillas o recetas?
Son precisamente eso, enfoques predefinidos, ya probados,
para tipos comunes de incidentes.
Un bloqueo de cuenta, un fallo de impresora, cosas así.
Aceleran la resolución usando pasos ya conocidos.
Vale.
Pero claro, no todos los incidentes son tan sencillos.
Existen los llamados incidentes mayores.
Que imagino que son los que provocan esas crisis de todo el
mundo a cubierta.
Tal cual.
Tienen un impacto muy, muy significativo en el negocio.
A veces lo paralizan y exigen una respuesta inmediata,
coordinada.
Pueden ser complejos, ¿sabes?
Con efectos en cascada.
Aquí entra en juego una figura clave,
el major incident manager, el MIM.
Y a menudo se usan enfoques como el swarming del que hablábamos
antes.
¿Y si no hay una solución definitiva a mano, qué se hace?
¿Rezar un poco?
Bueno.
Antes de rezar, se busca un workaround,
una solución temporal.
El clásico ejemplo es reiniciar el router cuando internet va
mal.
No arregla la causa de raíz, pero oye,
te permite seguir funcionando.
Ah, el famoso apagar y volver a encender,
el recurso universal.
Ese mismo.
Pero cuidado, ¿eh?
Depender constantemente de workarounds sin resolver el
problema de fondo genera lo que llamamos deuda técnica.
Deuda técnica.
Suena serio.
Y lo es.
Es como pedir un préstamo.
Te saca de la pura hora, pero acumula intereses en forma de
problemas futuros o mayor esfuerzo para arreglarlo
después.
Es un riesgo oculto si no se gestiona bien.
Deuda técnica.
Me quedo con el concepto.
Potente.
Vale. ¿Y cómo es el ciclo de vida típico de un incidente?
¿Desde que pasa hasta que, bueno, se cierra?
Simplificando mucho, las etapas son detección,
que idealmente es automática, con monitorización,
registro, documentar qué pasa, clasificación, priorizar,
dirigirlo a quien toca, diagnóstico,
investigar la causa, resolución, aplicar la solución,
sea temporal o definitiva, y cierre,
confirmar que todo va bien y documentar lo hecho.
Parece lógico, sí.
Y hay dos procesos principales funcionando aquí, ¿verdad?
No solo apagar fuegos.
Exactamente eso.
Exacto.
Por un lado, la gestión y resolución diaria de cada
incidente que ocurre, el día a día.
Y por otro, la revisión periódica de incidentes.
Esto es mirar atrás, analizar tendencias y ver cómo mejorar
todo el proceso continuamente.
Ah, y es vital que alguien sea dueño del incidente de
principio a fin, que haya una responsabilidad clara.
Fundamental esa responsabilidad, sí.
Ahora, ¿qué se necesita para que todo esto funcione bien?
Hablemos de los habilitadores, empezando por las personas y la
organización.
Pues mira, se necesitan roles definidos,
como el incident manager o el MIM que mencionamos.
Y cada vez más se tiende a estructuras menos jerárquicas,
más planas y colaborativas.
Aquí es donde brilla el swarming.
El swarming otra vez.
Explícalo un poco más.
¿Cómo funciona eso en la práctica?
Pues en vez de escalar el problema nivel a nivel,
¿sabes?
El típico L1, L2, L3, se junta un equipo con distintas
habilidades, un equipo multifuncional,
desde el principio para atacar juntos los incidentes
complejos.
Suena más directo, menos burocrático,
pero ¿no puede generar un poco de caos si todos opinan a la
vez?
Podría ser un riesgo si no se coordina bien, claro.
Pero la idea es que la colaboración sea enfocada,
dirigida.
Los beneficios suelen superar los riesgos.
Se resuelve más rápido, se evitan esos traspasos ineficientes
entre equipos y, además, el equipo aprende
colectivamente.
Fomenta una cultura de responsabilidad compartida,
sin buscar culpables, sino soluciones y aprendizaje
continuo.
Me gusta esa idea de cultura colaborativa y sin culpas.
Suena más sano.
¿Y qué hay de la información y la tecnología?
Sin datos y herramientas, poco se puede hacer, imagino.
Exacto.
Necesitas información fiable, de la arquitectura,
de los servicios afectados, de los SLA's, de todo.
Y registros de incidentes muy detallados,
qué pasó, quién intervino, cuándo, el impacto,
las acciones tomadas.
Y aquí, la automatización es absolutamente crucial.
La palabra mágica, automatización.
¿En qué partes se puede automatizar realmente?
Dame ejemplos.
En casi todas.
Detección automática con herramientas de monitorización,
registro a través de portales o incluso chatbots,
clasificación usando inteligencia artificial o
machine learning, diagnóstico con scripts automáticos que
hacen pruebas, resolución remota o incluso autocorrección para
ciertos fallos y el cierre mediante flujos de trabajo
automatizados.
Vaya, casi todo el ciclo.
Sí, la idea es liberar a los expertos humanos para las
tareas más complejas, las que requieren juicio y reducir los
errores humanos en tareas repetitivas.
Tiene todo el sentido.
Y no podemos olvidarnos de los socios y proveedores,
que hoy en día son parte de casi cualquier servicio tecnológico.
Cierto, cierto.
La mayoría de los servicios dependen de terceros.
Es vital tener acuerdos claros sobre cómo van a colaborar
ellos en la resolución de incidentes.
Necesitas canales de comunicación fluidos,
interfaces bien definidas, que todo funcione como una orquesta
bien afinada.
Claro, que no se pasen la pelota unos a otros.
Finalmente, ¿cómo sabemos si lo estamos haciendo bien?
¿Cuáles son los factores clave de éxito?
Pues los podríamos resumir en tres principales.
Detectar los incidentes lo antes posible,
resolverlos de forma rápida y eficiente y, muy importante,
mejorar continuamente cómo se gestionan.
Detectar pronto, resolver bien, mejorar siempre, me gusta.
Y esto se mide claro, no solo una sensación.
Por supuesto.
Se mide con métricas.
Tiempo medio de detección, tiempo medio de resolución,
el porcentaje de incidentes resueltos en el primer contacto,
la satisfacción del usuario, el nivel de automatización que
has alcanzado.
Medir es la base para poder mejorar, sin duda.
Perfecto.
Entonces, recapitulando un poco.
La gestión de incidentes busca restaurar el servicio
rápidamente.
Para ello, son esenciales procesos claros,
modelos reutilizables, una fuerte apuesta por la
automatización y enfoques colaborativos como el swarming.
Todo ello con una visión integral,
considerando las cuatro dimensiones de la gestión de
servicios y un foco constante en la mejora continua.
En esencia, sí.
Es construir la base para que los servicios tecnológicos sean
fiables y, bueno, inspiren confianza tanto dentro como
fuera de la organización.
Y aquí va una reflexión final para quien nos escucha.
Teniendo en cuenta todo esto, la automatización creciente,
el poder de la colaboración tipo swarming,
hasta qué punto un enfoque aún más proactivo y colaborativo
podría transformar radicalmente no sólo la fiabilidad de los
servicios, sino la propia relación de confianza entre una
organización y sus clientes.
Ahí lo dejo.
De qué pensar, desde luego.
Una buena pregunta para cerrar.
Gracias por acompañarnos en este análisis detallado.
Este análisis detallado de "Con Punto y Koma" ha sido traído a
ustedes por Lina IT Group.
Excelente análisis.
Gracias por acompañarnos y hasta el próximo episodio de ITIL
4 sin filtros, elevando el ITSM.
Hasta la próxima.
[MÚSICA]