Análisis de causa raíz (ACR) de los 5 porqués
Resumen
El Análisis de causa raíz (ACR) de los 5 porqués es una técnica estructurada de resolución de problemas en la que comienzas con una declaración del problema y preguntas "¿Por qué?" cinco veces en secuencia. Cada respuesta sirve de base para la siguiente pregunta. El objetivo es ir más allá de los síntomas y sacar a la luz la falla subyacente en el proceso o sistema que realmente puedas corregir.
Quién puede usarlo
Equipos de producto e ingeniería
Equipos de operaciones y DevOps
Equipos de soporte y servicio al cliente
Gestores de proyectos
Equipos de aseguramiento de la calidad
Cualquier persona que investigue incidencias o incidentes recurrentes
Cómo usarlo
Escribe una declaración del problema clara — qué ocurrió, cuándo y cuál fue el impacto.
Pregunta "¿Por qué ocurrió esto?" y registra la respuesta (Respuesta 1).
Pregunta "¿Por qué ocurrió la Respuesta 1?" y registra la respuesta (Respuesta 2).
Repite para las Respuestas 3, 4 y 5.
Detente cuando llegues a una causa que puedas abordar mediante un cambio de proceso o del sistema — esta es tu causa raíz.
Define las acciones correctivas: asigna a cada acción un propietario y una fecha límite.
Consejo: una buena causa raíz señala a un proceso o sistema, no a una persona. Si tu respuesta es un nombre, pregunta por qué una vez más.
Ejemplo
Declaración del problema: La página de pago estuvo caída durante 3 horas el 12 de agosto — aprox. $18 000 en pedidos perdidos y más de 40 tickets de soporte. (Investigado el 13 de agosto por el equipo de plataforma.)
Por qué 1: El servidor de pagos se quedó sin memoria y se bloqueó.
Por qué 2: El servicio de pagos tiene una fuga de memoria.
Por qué 3: La versión del 8 de agosto no cierra las conexiones antiguas de la base de datos.
Por qué 4: La versión nunca fue sometida a pruebas de carga antes de ponerse en producción.
Por qué 5: El checklist de lanzamiento no incluye un paso de pruebas de rendimiento.
Causa raíz: El proceso de lanzamiento no incluye un paso obligatorio de pruebas de carga y rendimiento.
Acciones correctivas:
Agregar prueba de carga automatizada al pipeline de CI (responsable de DevOps, 30 de agosto)
Configurar alertas de memoria al 80% de uso (equipo SRE, 22 de agosto)
Actualizar la checklist de lanzamiento y capacitar al equipo (gerente de ingeniería, 20 de agosto)
¡Saludos!
Khawaja Rizwan
