El método de los 5 porqués se basa en un postulado simple: cada síntoma oculta una causa, y cada causa oculta otra. El cuestionamiento iterativo permite rastrear la cadena hasta un palanca de acción concreta. Observamos que la mayoría de los fracasos en la aplicación no provienen del método en sí, sino de una mala calificación del problema inicial y de un cese prematuro del análisis.
Sesgo de selección en la cadena causal de los 5 porqués
El punto débil estructural del método rara vez se aborda en las guías prácticas: dos equipos competentes pueden producir cadenas causales diferentes a partir del mismo incidente. Cada “por qué” abre varias respuestas plausibles, y la elección de la rama seguida depende de la experiencia, las hipótesis implícitas y los datos disponibles en el momento del análisis.
Este sesgo de selección tiene una consecuencia directa. La acción correctiva implementada corrige una causa real, pero no necesariamente la causa que tiene más impacto en la recurrencia del problema. Recomendamos documentar sistemáticamente la evidencia asociada a cada respuesta: dato de producción, observación en el terreno, registro de calidad. Una respuesta no respaldada por un hecho verificable debe ser señalada como hipótesis y tratada como tal.
Para los problemas con una cadena causal única y rastreable, el método funciona de manera notable. Sin embargo, cuando varias fallas deben combinarse para producir el incidente, el análisis lineal se vuelve insuficiente. El diagrama de Ishikawa o el árbol de fallas permiten mapear las interacciones entre factores latentes.
Una guía completa que detalla el método de los 5 porqués en Nefa Blog describe los pasos de aplicación secuencial y las condiciones de éxito para un análisis riguroso.
Criterios de cese del análisis: cuándo superar o acortar las 5 iteraciones
El número cinco no es una regla metodológica estricta. El análisis se detiene cuando la causa identificada es controlable y está relacionada con una acción correctiva verificable, ya sea que se necesiten tres, cinco o más preguntas. Imponerse exactamente cinco iteraciones conduce a dos desviaciones opuestas: detenerse demasiado pronto en un síntoma intermedio, o forzar una sexta pregunta que no produce ninguna información útil.
El criterio de cese operativo se basa en tres condiciones acumulativas:
- La causa identificada está bajo el control directo del equipo o del proceso involucrado (podemos actuar sobre ella sin escalada jerárquica externa).
- Una prueba fáctica (medición, registro, observación) confirma el vínculo entre esta causa y el efecto observado.
- La acción correctiva prevista puede ser probada y su efectividad verificada en un plazo razonable.
Si la respuesta al último “por qué” es “error humano”, el análisis no ha terminado. Concluir sobre el error humano es una señal de cese prematuro. El siguiente paso consiste en identificar las condiciones del sistema que hicieron posible este error: diseño de la interfaz, carga de trabajo, ausencia de control, procedimiento inadecuado o supervisión deficiente.
Verificación de la acción correctiva tras el análisis de los 5 porqués
Identificar una causa raíz no demuestra que la solución funcione. Observamos regularmente equipos que cierran su análisis tan pronto como formulan el plan de acción, sin un ciclo de verificación. El método pierde así su finalidad: prevenir la recurrencia.
Cada acción correctiva debe ser objeto de un seguimiento estructurado. La verificación se centra en dos dimensiones: ¿se ha implementado la acción de acuerdo con lo previsto, y ha desaparecido o disminuido significativamente el efecto no deseado en un plazo definido de antemano?
La trampa clásica es medir el esfuerzo (formación impartida, procedimiento actualizado) en lugar del resultado (desaparición o reducción del incidente). Un indicador de resultado debe definirse antes de la implementación de la acción correctiva, no después.
Formalización mínima para trazar el análisis
Una tabla simple es suficiente para cada iteración:
| Nivel | Pregunta formulada | Respuesta fáctica | Prueba asociada |
|---|---|---|---|
| Por qué 1 | ¿Por qué ocurrió el incidente? | Respuesta documentada | Fuente del dato |
| Por qué 2 | ¿Por qué existe esta causa? | Respuesta documentada | Fuente del dato |
| Por qué N | Iteración hasta causa controlable | Respuesta documentada | Fuente del dato |
La columna “prueba asociada” es la más descuidada y la más útil. Obliga al equipo a distinguir un hecho verificado de una suposición. Sin prueba documentada, la respuesta sigue siendo una hipótesis, no una causa validada.
Límites estructurales y complementariedad con otras herramientas de análisis
El método de los 5 porqués sobresale en un ámbito preciso: un problema observable, una cadena causal dominante, un equipo que conoce el proceso. Fuera de este marco, produce resultados parciales.
Las situaciones en las que recomendamos combinar o reemplazar el enfoque:
- Problemas con causas múltiples independientes: el diagrama de Ishikawa permite estructurar las familias de causas antes de lanzar un 5 porqués en cada rama pertinente.
- Fallos sistémicos que implican interacciones entre subsistemas: el árbol de fallas modela las combinaciones de factores necesarios para la ocurrencia del incidente.
- Incidentes con una fuerte componente organizacional: el análisis debe explorar las condiciones sistémicas (diseño, supervisión, recursos) en lugar de la única secuencia técnica.
El error frecuente consiste en aplicar los 5 porqués por defecto, independientemente del tipo de problema. La elección de la herramienta de análisis debería depender de la estructura causal supuesta, no de la facilidad de implementación.
La resolución de problemas gana en fiabilidad cuando el equipo domina varios métodos y sabe arbitrar entre ellos según el contexto. Los 5 porqués siguen siendo un primer reflejo pertinente para los incidentes comunes con cadena causal simple, siempre que se respete la rigurosidad de la prueba en cada iteración y nunca se confunda la identificación de una causa con la confirmación de su tratamiento.
