Por qué cerrar tickets no significa cerrar causas raíz

Considere este escenario. El servicio del core bancario volvió. Los usuarios pueden ingresar. Las operaciones pendientes fueron procesadas. El proveedor confirmó estabilidad. El ticket del incidente tecnológicofinalmente aparece como CERRADO.

Después de varias horas de tensión, el equipo siente que puede volver a la normalidad, y probablemente sea cierto. El incidente terminó, pero hay una pregunta que convendría hacer antes de pasar a otra cosa:

¿También desapareció el riesgo que lo provocó?

No necesariamente. En muchas organizaciones somos bastante buenos recuperando servicios. Donde todavía tenemos espacio para mejorar es en asegurarnos de que el mismo problema no vuelva a aparecer unas semanas o unos meses después.

Cerrar el incidente y cerrar la causa son dos cosas diferentes

Cuando un servicio crítico falla, la prioridad es clara: recuperar. Se movilizan Tecnología, Operaciones, Seguridad, Continuidad, proveedores y, dependiendo de la magnitud, Riesgos y Alta Dirección. Durante esas primeras horas nadie debería estar pensando en preparar un informe perfecto sobre causa raíz.

Hay que contener la interrupción, recuperar y proteger el servicio.

El problema aparece después, cuando vuelve la normalidad, también regresan los pendientes, proyectos, reuniones y prioridades anteriores. Entonces sucede algo bastante humano: como el sistema ya funciona, el incidente pierde urgencia. El ticket se cierra, la investigación queda pendiente y la organización continúa operando con una vulnerabilidad que quizá sigue exactamente donde estaba antes.

“Se reinició el servicio” no es una causa raíz

Algunos cierres de incidentes tecnológicos describen muy bien qué se hizo para recuperar:

“Se reinició el servidor, se restauró la conexión, se amplió la capacidad y se corrigió la configuración.” Todo eso puede ser técnicamente correcto, pero responde a: ¿Cómo recuperamos?

No necesariamente a ¿Por qué ocurrió? Si un componente necesitó reiniciarse, la pregunta sigue abierta.

• ¿Por qué llegó a ese estado?

• ¿Por qué el monitoreo no lo detectó antes?

• ¿Por qué no funcionó el mecanismo automático de recuperación?

• ¿Por qué una falla técnica llegó a afectar un servicio crítico?

• ¿Por qué la arquitectura permitió que ese componente se convirtiera en un punto de interrupción?

La primera respuesta suele explicar el síntoma. Las siguientes comienzan a acercarnos al riesgo.

El segundo incidente cambia la conversación

Imaginemos una interrupción de 35 minutos, se recupera el servicio. El impacto es manejable. Se abre un plan de acción. Tres meses después ocurre nuevamente, pero esta vez dura 50 minutos. Se recupera y se actualiza el plan. Cinco meses más tarde vuelve a suceder pero ahora la pregunta ya no debería ser:

“¿Por qué volvió a fallar el sistema?”

También deberíamos preguntar:

“¿Por qué nuestra gestión del primer incidente no evitó el tercero?”

Cuando un evento se repite, ya no estamos solamente frente a una falla tecnológica u operacional, también puede existir una falla en nuestro proceso de aprendizaje.

Las causas raíz rara vez pertenecen a una sola categoría

Existe una tendencia natural a buscar una explicación técnica.

• Falló el servidor.

• Falló la aplicación.

• Falló la red.

• Falló el proveedor.

Pero detrás de un incidente material suele existir una combinación, tal vez hubo una falla tecnológica, pero también un cambio mal evaluado.

• El cambio pasó porque el control era débil,

• El control era débil porque el proceso había crecido sin actualizarse.

• Nadie detectó la situación porque el KRI observaba disponibilidad, pero no degradación.

• La recuperación demoró porque el procedimiento estaba desactualizado.

• Y la organización dependía de una persona que sabía cómo resolverlo.

¿Cuál fue entonces la causa raíz? Probablemente no exista una única respuesta, por eso un buen análisis debería mirar, al menos: personas, procesos, tecnología, datos, terceros y controles.

No para llenar seis casillas, sino para entender cómo varias condiciones terminaron alineándose.

Hay acciones correctivas que solamente trasladan el problema

Después de un incidente es habitual encontrar planes como:

• “Actualizar procedimiento.”

• “Capacitar al personal.”

• “Incrementar monitoreo.”

• “Revisar configuración.”

• “Coordinar con el proveedor.”

• Son acciones razonables.

Pero también son peligrosamente fáciles de cerrar, para ello se actualiza el documento, se realiza la capacitación, se crea una nueva alerta. Se concluye la reunión y se da el plan completado pero ¿La exposición del riesgo disminuyó? Eso todavía necesitamos demostrarlo. La diferencia está entre verificar que la acción fue ejecutada y comprobar que la causa fue tratada.

Quizás deberíamos dejar de medir solamente planes cerrados

Un dashboard puede mostrar:

Planes de acción completados: 96 %. Suena bien.

Pero sería interesante acompañarlo con otras métricas:

• ¿Cuántos incidentes son recurrentes?

• ¿Cuántas causas raíz se repiten?

• ¿Cuántos planes cerrados estuvieron asociados posteriormente a nuevos incidentes?

• ¿Cuánto tiempo permanece abierta una causa crítica?

• ¿Cuántos incidentes se cerraron sin RCA?

• ¿Cuántas acciones solamente modificaron documentación?

• ¿Cuántas fueron validadas después de su implementación?

Ahí comenzamos a medir algo diferente, no cuánto trabajo administrativo completamos sino cuánto aprendió realmente la organización.

Una acción correctiva también necesita una prueba

Si después de una caída modificamos la arquitectura, deberíamos comprobar que el escenario anterior ya no genera el mismo impacto.

Si cambiamos el procedimiento, deberíamos probarlo.

Si incorporamos un control, deberíamos evaluar su efectividad.

Si el proveedor implementó una mejora, deberíamos solicitar evidencia.

Si agregamos capacidad, deberíamos realizar una prueba de carga.

Cerrar una acción sin validar su resultado es parecido a instalar un control y asumir que funciona porque existe.

Los “casi incidentes” también cuentan una historia

No deberíamos esperar una nueva interrupción material para descubrir que el problema continúa.

A veces las señales aparecen antes con microcortes, reinicios, errores intermitentes, alertas repetidas, excepciones manuales, incremento de tiempos de respuesta, fallas menores del proveedor o reprocesos.

Individualmente pueden parecer poco relevantes, pero después de un incidente material adquieren otro significado. Pueden estar diciendo “La causa todavía está aquí”, por eso el seguimiento posterior debería observar no solamente si el plan fue cerrado, sino si las señales que precedieron al incidente están desapareciendo.

¿Cuándo deberíamos considerar realmente cerrado un incidente?

Quizás necesitemos separar tres momentos:

Servicio recuperado. La operación vuelve a un nivel aceptable.

Causa identificada y tratada. Entendemos qué ocurrió y ejecutamos las acciones necesarias.

Efectividad comprobada. Tenemos evidencia de que las acciones redujeron la probabilidad o el impacto de recurrencia.

Solamente entonces podemos hablar de aprendizaje completo. No todos los incidentes necesitarán el mismo nivel de análisis. Sería absurdo investigar una interrupción menor como si fuera una crisis sistémica. La profundidad debería ser proporcional a materialidad, recurrencia, criticidad y potencial de impacto, pero los incidentes importantes merecen algo más que un ticket cerrado.

La pregunta para el Comité

Cuando se presenta un incidente material al Comité de Riesgos, una pregunta habitual es “¿Ya fue solucionado?”

Podríamos cambiarla ligeramente “¿Qué evidencia tenemos de que no volverá a ocurrir por la misma causa?”

La respuesta probablemente revele mucho más sobre nuestra madurez de riesgo.

Reflexión final

Toda organización tendrá incidentes, pretender eliminarlos por completo no es realista. La diferencia está en lo que hacemos después y una organización frágil recupera y continúa pero una organización más madura recupera, entiende, corrige y comprueba.

El verdadero costo de un incidente no está solamente en los minutos de indisponibilidad o en la pérdida económica inmediata. También está en desaprovechar la oportunidad de aprender antes del siguiente evento, por eso, la próxima vez que aparezca la palabra CERRADO en un incidente material, quizá convenga hacer una última pregunta: ¿Cerramos el ticket o cerramos realmente la causa?

Porque el sistema puede haber vuelto a funcionar y el riesgo seguir exactamente donde estaba.