#PI_DECIDE #misconceptions
An English version is available here.
En la entrada sobre qué suele fallar en un diagrama de 5 porqués explicaba por qué prefiero el formato en gota (“tear drop”) al Ishikawa, con una animación que reconstruía el proceso a partir de un caso de rebaba en una línea de inyección.
He ampliado ese análisis con tres animaciones del mismo caso y una guía interactiva que sirve como punto de entrada a todo lo demás. La guía empieza con tres preguntas (dónde va a trabajar el grupo, cómo suele arrancar y qué necesitas al terminar) y devuelve una recomendación. Debajo hay un mapa con doce criterios en el que cada formato aparece marcado según ayude, dependa del caso o estorbe, y al pulsar cada fila se abre un comentario más desarrollado.
Las animaciones son la de la gota, la del Ishikawa y la de la lista indentada. La de la gota termina enseñando el código Mermaid que es una forma rápida de convertir los posits en texto plano sin perder las relaciones. Para quien prefiera verlo todo de golpe hay también una tabla resumen con los mismos criterios.
A pesar de que prefiero el diagrama de gota, éste también tiene sus trampas. Como no hay categorías que recuerden otros frentes, favorece la visión de túnel (se profundiza en las primeras ramas y la gota parece terminada aunque falte una entera), y comparte con la lista el síndrome de la página en blanco. Ahí las 6M del Ishikawa sí ayudan, aunque yo las sigo usando como lista de comprobación para arrancar o para repasar al final, no como estructura del diagrama.
Otro aspecto a remarcar es si un mismo posit puede tener dos flechas hacia ramas distintas. En el Ishikawa no queda más remedio que escribir la nota dos veces, y en la lista hay que repetir la línea o dejar una referencia del tipo “ver línea 8” que luego hay que mantener al día. En un diagrama de gota añades una relación y ya está.
La lista tiene más a favor de lo que parece. Para trabajar en remoto con gente que no se maneja bien en pizarras digitales (que es más habitual de lo que solemos suponer) probablemente es la opción más segura, y mover una rama entera es cortar, pegar y tabular. Lo que pierde es la vista de conjunto: con veinte líneas ya no se ve qué rama se ha quedado corta.
Referencias:
Marin-Garcia, J. A. (2026, 29 de septiembre). Del primer borrador a la causa raíz: qué suele fallar en un diagrama de 5 porqués [Entrada de blog]. Blog de Juan A. Marin-Garcia. https://jamg.blogs.upv.es/4582/
Marin-Garcia, J. A., Garcia-Sabater, J. J., Garcia-Sabater, J. P., & Maheut, J. (2020). Protocol: Triple Diamond method for problem solving and design thinking. Rubric validation. WPOM-Working Papers on Operations Management, 11(2), 49–68. https://doi.org/10.4995/wpom.v11i2.14776
Visitas: 9