5 Whys: llegar a la causa raíz preguntando por qué, 5 veces

En una línea

5 Whys (5 Por qués) es una técnica de resolución de problemas que consiste en preguntar "¿por qué?" en cadena — cada respuesta se convierte en la base de la siguiente pregunta — hasta llegar a una causa sobre la que realmente se puede actuar, en lugar de quedarse en el síntoma superficial.

Qué es

La técnica fue desarrollada por Sakichi Toyoda para Toyota Industries Corporation, y más tarde se integró como práctica básica del Sistema de Producción Toyota (TPS), impulsado por Taiichi Ohno. La idea de fondo es simple: cuando aparece un problema, la tentación natural es culpar a otro, a un factor externo o a la mala suerte — pero la causa real casi siempre está más cerca de lo que parece, dentro del propio proceso.

Preguntar "por qué" cinco veces no es una fórmula mágica ni una regla rígida: la propia fuente aclara que cinco es solo una guía práctica para pelar las capas de síntomas que tapan la causa — en algunos casos hacen falta menos preguntas, en otros, más.

Para que la técnica funcione, hacen falta tres condiciones básicas:

• Un enunciado del problema preciso y completo (no algo vago como "la máquina falla mucho")
• Honestidad total al responder cada pregunta, sin buscar quedar bien ni cubrir a nadie
• Decisión real de llegar hasta el fondo y no conformarse con la primera respuesta cómoda

5 Whys es una herramienta genérica de análisis de causa raíz (RCA): cuando no alcanza para ver con claridad de dónde viene el problema, se puede combinar con otras herramientas de este mismo pilar como el diagrama de Ishikawa, o técnicas más estructuradas como el análisis de barreras o el árbol de factores causales.

Para qué sirve

Sirve para cualquier problema puntual y acotado donde se sospecha que la causa visible es en realidad un síntoma de algo más profundo: una falla de equipo que se repite, un incidente de seguridad, un reclamo de calidad, un cambio de turno que no salió como estaba planeado. No es la herramienta indicada para problemas con muchas variables interrelacionadas actuando al mismo tiempo — ahí conviene un Ishikawa o un análisis más formal antes de encadenar preguntas.

Cómo se aplica

El proceso descrito por la fuente tiene cinco pasos, pensados para hacerse en equipo (funciona mejor con varias personas involucradas directamente en el problema, no una sola persona especulando sola):

1. Reunir al equipo y acordar juntos el enunciado exacto del problema.
2. Preguntar el primer "por qué": probablemente salgan tres o cuatro respuestas razonables — anotarlas todas (pizarra, tarjetas, planilla).
3. Repetir "por qué" para cada una de esas respuestas, cuatro veces más — sin descartar ninguna rama plausible. Si con menos de cinco preguntas ya no sale información nueva, ahí está la causa raíz; si hace falta, se sigue más allá de la quinta.
4. Entre todas las respuestas a la última pregunta, buscar las causas sistémicas (no individuales) y acordar en equipo cuál es la más probable.
5. Definir la acción correctiva que elimina esa causa raíz del sistema — no una acción que corrija el síntoma de arriba.

Ejemplo real

En 2004, durante una recorrida por un centro de distribución (Fulfillment Center) de Amazon.com, Jeff Bezos se enteró de un incidente de seguridad: un operario se había lastimado el pulgar. En lugar de pedir un informe por escrito, se paró frente a un pizarrón y encadenó las preguntas ahí mismo:

1. ¿Por qué se lastimó el pulgar? → Porque se le quedó atrapado en la cinta transportadora.
2. ¿Por qué se le atrapó el pulgar en la cinta? → Porque estaba persiguiendo su bolso, que iba arriba de la cinta en movimiento.
3. ¿Por qué perseguía el bolso? → Porque lo había dejado apoyado sobre la cinta, y esta arrancó sin que él lo esperara.
4. ¿Por qué había dejado el bolso sobre la cinta? → Porque la estaba usando como si fuera una mesa.

Con esa cuarta respuesta ya apareció la causa raíz: no había ninguna superficie cerca del puesto para dejar objetos personales, así que el operario improvisó usando la cinta transportadora como mesa. La acción correctiva no fue "pedirle que tenga más cuidado" — fue instalar mesas en los puestos que las necesitaban, actualizar la capacitación en seguridad, y revisar el trabajo estandarizado de mantenimiento preventivo de la línea.

Vale la aclaración que trae la propia fuente: el "5" es una guía, no una regla fija. En este caso real la causa raíz salió a la luz en la cuarta pregunta, no en la quinta — y eso está bien: lo importante es seguir preguntando hasta que la siguiente respuesta ya no aporte información nueva, sea antes o después de la quinta vuelta.

Cómo armarla

Para completarlo en pantalla (lo que cargás se guarda en tu navegador), usá la herramienta interactiva.

Copiá esta secuencia y completala con tu equipo, una respuesta por vez, antes de pasar a la siguiente pregunta:

1. Problema a analizar: (descripción concreta y acotada del problema)
2. ¿Por qué ocurrió el problema?
3. ¿Por qué pasó eso?
4. ¿Por qué pasó eso?
5. ¿Por qué pasó eso?
6. ¿Por qué pasó eso? (la respuesta a esta pregunta es tu candidato a causa raíz)
7. Causa raíz identificada:
8. Acción correctiva:

Beneficios

• No requiere herramientas estadísticas ni entrenamiento especial: cualquier equipo la puede aplicar con un pizarrón y media hora
• Es rápida: se resuelve en una sola sesión de trabajo, a diferencia de análisis más formales que llevan días
• Al hacerse en equipo, empuja la conversación hacia causas del sistema y del proceso, en vez de quedarse en "quién tuvo la culpa"
• Combina bien con otras herramientas de este pilar: sirve para abrir en profundidad cualquier "hueso" de un diagrama de Ishikawa, o cualquier causa hipotética de un RCA más amplio

Limitaciones a tener en cuenta

La misma fuente advierte que la técnica recibe críticas por ser demasiado básica para garantizar que se llega a una causa raíz real y no a otro síntoma más profundo. Los motivos más comunes:

• El equipo tiende a frenar en el primer síntoma convincente, sin bajar un nivel más
• Las respuestas dependen del conocimiento y la experiencia de quienes preguntan — si nadie en la sala sabe lo suficiente, la cadena se corta antes de tiempo
• Falta de facilitación: sin alguien que empuje a seguir preguntando, es fácil conformarse
• Baja repetibilidad: dos equipos distintos analizando el mismo problema pueden llegar a causas raíz diferentes

La forma de mitigar esto es verificar cada respuesta contra la realidad (no responder por deducción o intuición) antes de pasar a la siguiente pregunta, y no cerrar el análisis hasta confirmar que la causa encontrada explica el problema completo.

Aplicalo a tu problema

En resumen

5 Whys es la herramienta de arranque del análisis de causa raíz: nació en Toyota con Sakichi Toyoda y se volvió práctica estándar del TPS porque es simple, rápida y no necesita capacitación previa. Preguntar "por qué" en cadena — con honestidad y verificando cada respuesta antes de seguir — corre el foco de "quién tuvo la culpa" hacia "qué parte del sistema permitió que esto pasara". Es un buen primer paso para casi cualquier problema puntual; cuando el problema tiene demasiadas causas posibles actuando en simultáneo, conviene apoyarse además en un Ishikawa o en un RCA más estructurado.