[Música]
Hola, hola. Bienvenidos de nuevo a ITIL4 Sin Filtros,
el espacio donde hablamos de gestión de servicios sin vueltas ni jerga innecesaria.
Yo soy Juan Carlos.
Y yo soy Camila.
Y hoy vamos a hablar de una de esas prácticas que…
salvan el día en silencio.
Nunca se lleva los aplausos, pero siempre está ahí.
Mjmm, hablamos de la gestión de problemas.
Piensa en ella como el técnico que está detrás del escenario en un concierto.
Si todo funciona, nadie lo nota.
Pero si algo falla, se cae todo el show.
[Risa]
Tal cual.
Y ojo, la gestión de problemas no se trata de resolver incidentes cuando ocurren.
Para eso está la gestión de incidentes.
Esto va más allá.
Se trata de evitar que vuelvan a pasar.
Exactamente.
Imagina que tu sistema se cae todos los lunes a las 9 de la mañana.
Gestión de incidentes lo levanta.
Gestión de problemas se pregunta, ¿por qué se cae cada lunes?
Mhm.
Y según ITL4, el objetivo de esta práctica es clarísimo.
Reducir tanto la probabilidad como el impacto de los incidentes,
identificando sus causas reales.
Sí, es como ser un detective digital.
Sin gabardina, pero con logs y dashboards.
Hoy vamos a desmenuzar esta práctica paso a paso,
con ejemplos reales y sin saltearnos nada.
Bueno, Juan, la gestión de problemas se divide en tres fases.
Identificación del problema, control del problema y control del error.
Sí, es como decir qué está fallando, por qué está fallando
y, por último, qué hacemos con eso.
Tal cual.
En la primera fase, notas que algo raro está pasando,
incidentes que se repiten, patrones extraños
o algún usuario reporta algo inusual.
Después, en el control del problema se investiga a fondo.
Logs, métricas, hipótesis, colaboración.
Se activa el modelo de mejora continua.
Y, por último, el control del error.
Ahí se decide si conviene aplicar una solución definitiva,
implementar un workaround o simplemente dejarlo bajo vigilancia.
Claro. No todos los problemas se resuelven en el acto.
Algunos se mantienen activos por un buen tiempo.
Pero activos intencionalmente.
Deben estar documentados, asignados y, sobre todo, revisados regularmente.
Entonces, hablemos de enfoque.
La gestión de problemas puede ser reactiva o proactiva.
Sí, reactiva es cuando ya pasó un incidente
y quieres entender qué lo causó para que no se repita.
Así es.
En proactiva, bueno, es detectar un problema antes de que se convierta en incidente.
Puede venir de una alerta, un boletín de seguridad,
una auditoría técnica, incluso de la comunidad de usuarios.
Exacto.
Por ejemplo, un proveedor publica una vulnerabilidad crítica.
Actúas antes de que explote. Eso es gestión proactiva.
Pero ojo, incluso lo proactivo sigue siendo una reacción al problema.
No evitas que exista el error, pero sí que te afecte.
Muy cierto. Se recomienda aplicar ambos enfoques.
Lo importante es encontrar el equilibrio.
Una vez que detectas un problema, lo primero es registrarlo.
Eso marca el inicio del proceso.
Después, viene la clasificación.
Debes entender qué tipo de problema es
y a qué equipo o rol le corresponde investigarlo.
Claro, ¿es algo de red, base de datos, un error en el contrato con un proveedor?
La clasificación debe ayudarte a dirigirlo al lugar correcto.
Y eso depende mucho de cómo esté organizada tu empresa.
Si trabajas por productos, clasificas por producto.
Si es por dominios técnicos, sigues esa línea.
También se considera el impacto y la urgencia.
Si el problema afecta al sistema de pagos en plena temporada alta, bueno, no puedes esperar hasta mañana.
Pero si ya tienes un workaround que lo mantiene bajo control, quizás no sea urgente.
Todo depende del contexto del negocio.
Entonces, ya registraste y clasificaste el problema.
¿Qué sigue?
No se trata solo de lanzar un ticket y cruzar los dedos.
Para nada.
Aquí entra en juego una técnica clave llamada "swarming".
Y te digo, es de mis favoritas.
La mía también.
El swarming es básicamente juntar a las personas correctas.
Puede ser gente de desarrollo, soporte, infraestructura.
Y que todos colaboren en tiempo real hasta encontrar la causa.
Sí.
Y es súper útil cuando el problema, eh, no está claramente en un solo dominio.
A veces involucra varias áreas al mismo tiempo.
Ya sabes.
¡Exacto!
Es mucho mejor que estar rebotando tickets de un equipo a otro.
Y, siendo sinceros, es más eficiente.
Y hasta divertido, si te gusta resolver rompecabezas.
La idea del swarming es lograr claridad.
Cuando todos aportan desde su especialidad, el análisis avanza más rápido.
Y se puede asignar el problema con más precisión.
Sí.
O en algunos casos, eh, se detecta un workaround que se puede aplicar de inmediato.
Y eso también es valioso.
Ahora, hay situaciones donde no se puede resolver el problema en el momento.
Tal vez porque la solución es muy costosa.
O depende de un proveedor externo.
En esos casos, lo que se hace es registrar un error conocido y aplicar un workaround.
Es decir, una solución temporal que reduce el impacto mientras se resuelve el fondo del asunto.
Exactamente.
Es como ponerle una curita a una fuga mientras se consigue la pieza de repuesto.
No es lo ideal, pero mantiene el servicio funcionando.
Pero ojo, esos errores conocidos generan lo que llamamos deuda técnica.
Cada vez que evitamos resolver un problema de raíz, incrementamos el trabajo pendiente.
Y esa deuda se vuelve costosa con el tiempo.
Porque ralentiza futuros desarrollos, aumenta riesgos y puede ocasionar incidentes repetitivos.
Por eso, ITIL recomienda revisar periódicamente todos los errores conocidos.
Ver si ya existe una solución viable o si es momento de mejorar el workaround.
Y también asegurarse de que esa solución temporal no se vuelva permanente por costumbre.
Porque pasa más de lo que uno cree.
Lo sé, porque he estado ahí.
Ahora, hablemos de algo que realmente ayuda a gestionar los problemas de forma eficiente.
Los modelos de problemas.
Sí, los modelos son como plantillas o guías paso a paso para problemas que ya se han visto antes.
Por ejemplo, si cada cierto tiempo se cae un servicio por un tema de caché,
y ya sabes cómo solucionarlo, ¿para qué reinventar la rueda?
¡Exacto! Documentas el patrón, las acciones recomendadas, los equipos involucrados y hasta posibles medidas preventivas.
Todo eso queda en el modelo.
Y eso reduce mucho el tiempo de análisis cuando vuelve a ocurrir.
Además, ayuda a los equipos nuevos o menos experimentados a actuar con confianza.
Y ni hablar del valor que tiene para la mesa de servicio.
Cuando pueden acceder a un modelo claro, todo fluye mejor.
La verdad, usar modelos es una señal de madurez operativa.
Te permite escalar el conocimiento sin depender de una sola persona.
Bueno, Juan, llega un punto en el que te preguntas, ¿cómo sabemos si todo esto está funcionando bien?
Buena pregunta. O sea, puedes tener el proceso súper definido, pero si no lo mides…
es como manejar con los ojos cerrados.
Y aquí es donde entran las métricas. No estamos hablando de contar tickets a lo loco, ¿eh?
Se trata de medir impacto, no actividad.
Por ejemplo, una métrica clave es la cantidad de incidentes que se resolvieron gracias a un análisis de problema,
no solo por reiniciar un servidor.
O también el número de errores conocidos que siguen abiertos y cuánto están afectando al negocio.
Hay una métrica que a mí me gusta mucho, el Índice de Desempeño en Gestión de Problemas.
Lo llaman PPI, Problem Performance Index.
¿Y cómo funciona?
Se calcula considerando los problemas nuevos, los que se resolvieron y los que se cerraron.
Básicamente, mide si estás identificando y resolviendo, no solo acumulando tareas.
Eso está buenísimo, porque te obliga a encontrar un equilibrio entre detectar y actuar.
No sirve de nada llenar el backlog si nadie hace nada con eso.
Y ojo, estas métricas deben adaptarse al contexto de tu organización.
No hay una fórmula mágica, lo importante es que reflejen valor real.
Exacto. O sea, si el área de ventas pierde $100,000 dólares al mes por un error no resuelto,
esa es la métrica que importa. Punto.
Ahora que ya entendemos el qué y el cómo,
em, hablemos del con qué.
Las herramientas marcan una diferencia enorme.
Totalmente.
Y no estamos hablando solo de automatizar por automatizar.
La clave es que las herramientas se adapten al proceso, no al revés.
Exacto. Por ejemplo, las plataformas de monitoreo pueden detectar comportamientos anómalos
antes de que un usuario llame a la mesa de servicio.
Eso permite una identificación proactiva.
Y si además integras inteligencia artificial o análisis predictivo,
puedes identificar patrones entre incidentes que, a simple vista, parecerían aislados.
Eso es poder real. Y ni hablar de los sistemas de gestión del conocimiento.
Cuando están bien organizados, te dan acceso inmediato a errores conocidos,
soluciones previas y workarounds documentados.
Sí, pero ojo, de nada sirve tener mil artículos si nadie los encuentra.
Ahí entra en juego el diseño del sistema, la estructura, los filtros, todo eso importa.
¡Cuántas veces he visto bases de conocimiento que son más laberintos que ayuda!
Uf, muchas veces. Y bueno, también está el tema de los flujos de trabajo.
Herramientas como plataformas ITSM que te permiten relacionar problemas con incidentes, cambios, activos…
Y eso permite trazabilidad completa.
Sabes qué cambio resolvió qué problema, qué error lo causó y a qué componente estaba vinculado.
Eso es oro puro para mejorar continuamente.
Y no olvidemos el monitoreo de errores conocidos.
Si un workaround lleva seis meses activo, la herramienta debería decirte "revísalo,
ya es hora de aplicar una solución definitiva".
Las herramientas no son mágicas, pero cuando están bien configuradas, se convierten en un aliado estratégico.
Te ayudan a escalar, priorizar y a enfocarte en lo que realmente importa.
Juan, algo que no podemos dejar fuera es el papel de los proveedores y terceros.
Porque, muchas veces, el problema ni siquiera está dentro de tu infraestructura.
Exactamente. Puede que el error esté en una API de terceros, en un componente de red de alquilado,
o incluso en un servicio en la nube que no controlas directamente.
Y cuando eso pasa, si no lo tienes previsto en tus procesos, te quedas cruzado de brazos.
Por eso, ITIL recomienda que tus modelos de problema incluyan instrucciones claras sobre cómo escalar a terceros,
qué información compartir y cómo hacer seguimiento.
Y eso también se tiene que reflejar en los contratos.
Si dependes de un proveedor para resolver algo crítico, tiene que haber un acuerdo formal que defina tiempos,
responsabilidades y canales de comunicación y escalamiento.
Ahora, vayamos más lejos. Hablemos sobre lo que ITIL propone para medir la madurez de esta práctica, usando niveles de capacidad.
Son cinco niveles, desde el más básico, donde la práctica es improvisada y poco estructurada,
hasta el más alto, donde se mejora continuamente con base en métricas y resultados reales.
Y ojo, no se trata de llegar al nivel 5 en todo. Eso sería… costoso y probablemente innecesario.
Sí, no todas las organizaciones necesitan ese nivel de sofisticación.
Lo importante es definir en qué procesos vale la pena invertir más capacidad.
Claro, si tienes un servicio crítico, como pagos o atención al cliente,
ahí sí conviene llegar a un nivel alto de madurez en la gestión de problemas.
Y en otros servicios menos críticos, tal vez te basta con tener un nivel intermedio bien implementado.
En resumen, no se trata de hacerlo perfecto en todas partes,
sino de alinear tu nivel de capacidad con lo que realmente necesita el negocio.
Bueno, Juan, antes de cerrar, ¿te parece que compartamos algunos consejos prácticos que nuestros oyentes pueden aplicar en su día a día?
Claro que sí, porque una cosa es la teoría y otra es cuando te cae el problema un viernes a las 6 de la tarde.
¡Literal! Así que, vamos con algunos puntos clave.
Primero, empieza a registrar problemas hoy mismo.
Aunque el proceso no esté del todo afinado, si no hay visibilidad, no hay mejora.
Totalmente.
Segundo, la gestión de problemas no es una función administrativa, es una práctica estratégica.
Se trata de reducir riesgos, proteger ingresos y dar continuidad al negocio.
Tercero, publica tu lista de problemas más importantes.
Que sea visible para todos. Ya sabes, cuando los problemas están sobre la mesa, aparecen soluciones inesperadas.
Cuarto, organiza un grupo multidisciplinario.
El enfoque de Swarming funciona porque une talentos diversos para atacar un problema desde todos los ángulos.
Y eso muchas veces acorta días de análisis.
Quinto consejo, y este es clave, prioriza con el foco en el valor.
No todo lo técnico es urgente. A veces un problema pequeño en un proceso clave puede tener un impacto gigante.
Y no olvides los principios guía de ITIL.
Especialmente, comienza donde te encuentres, colabora y promueve la visibilidad.
Y manténlo simple y práctico.
Y simple no significa superficial, significa enfocado.
Bien pensado, bien ejecutado.
Bueno, si llegaste hasta aquí, felicidades.
Hoy te llevas no solo la teoría, sino también una forma más clara de ver los problemas y actuar sobre ellos.
Y si has aprendido algo, compártelo con tus colegas.
O con esa persona que siempre dice, "Esto se arregla reiniciando".
Que escuche este episodio, por favor.
Te esperamos en el próximo episodio de ITIL 4 Sin Filtros,
donde convertimos las buenas prácticas en conversaciones reales.
Hasta la próxima. Y recuerda, no solo apagues el incendio, encuentra lo que lo está provocando.
[Música]