La mayoría de los Ishikawa que he visto en planta terminan igual: pegados en la pared, con doce ramas llenas y ni una sola causa comprobada. Se ven bien. Y el problema regresa al mes siguiente con otro nombre.
Llevo 28 años en manufactura, entre calidad, operaciones y mejora continua. He armado esta herramienta de las dos formas: la que ordena un problema y la que solo lo decora. La diferencia no está en el dibujo ni en cuántas ramas le pongas. Está en una línea que escribo antes de convocar a nadie, y que casi nadie escribe.
Para qué sirve, y para qué no
El diagrama de causa y efecto hace una sola cosa bien: obliga a un grupo a poner sobre la mesa todas las causas posibles antes de casarse con la primera. Nada más. No comprueba, no prioriza y no resuelve. Es el paso donde abres el abanico.
Ahí está la primera trampa. Como se ve completo cuando está lleno, el equipo confunde llenarlo con haberlo resuelto. Se toma la foto, se sube al reporte, y el defecto sigue saliendo en el segundo turno.
Las 6M y el error que casi nadie corrige
Las ramas clásicas son seis: mano de obra, máquina, método, material, medición y medio ambiente. En servicios funcionan igual cambiando los nombres. El error típico está en lo que se escribe dentro de la rama, no en cómo se llama la rama.
Si en mano de obra alguien anota "falta de capacitación", ahí se acabó el análisis. Eso es un juicio, no una causa. Una causa se escribe de forma que alguien pueda ir a verificarla al piso hoy mismo: "el operador del segundo turno no tiene la hoja de trabajo estandarizado en su estación". Esa sí se puede ir a ver.
Aun corrigiendo eso, la mayoría de las sesiones se siguen cayendo. Y se caen siempre en el mismo minuto.
La junta donde se cae
Minuto cuarenta. El pizarrón lleno. Alguien dice que el problema es el material, el de compras dice que el material entró dentro de especificación, y el de calidad saca un correo de hace tres semanas. Nadie tiene con qué cerrar la discusión, así que gana el que habla más fuerte o el que tiene más puesto.
Yo he estado en esa junta muchas veces, de los dos lados de la mesa. Sales con doce causas, cero evidencia y un plan de acción que en realidad es una lista de buenas intenciones. Un mes después alguien vuelve a convocar por lo mismo.
No es que el equipo sea flojo ni que la herramienta esté mal. Es que empezaron a llenar ramas sin haber definido qué estaban resolviendo.
Lo que cuesta cada vuelta
Saca la cuenta de la última vez. Ocho personas, hora y media, más el tiempo de quien preparó la presentación. Eso es un día de trabajo de alguien, y es la parte barata.
Lo caro es el mes que sigue produciendo con el defecto adentro, la contención que alguien tiene que sostener a mano, y el cliente que ya se dio cuenta. Cuando el mismo problema se convoca tres veces, lo que se gastó no fue tiempo de junta: fue la confianza de que ese equipo puede resolver.
Y todo eso se decide antes de que alguien dibuje la primera rama.
La línea que escribo antes de convocar a nadie
Antes de citar a la primera persona, escribo el problema en una sola línea con cuatro datos: qué falla, dónde, desde cuándo y cuánto.
"Rechazo por rebaba en la operación 40, línea 2, desde el cambio de lote del 14 de julio, 3.2% contra un objetivo de 0.5%."
Con esa línea escrita pasan dos cosas. La primera es que la mitad de las causas que el equipo iba a proponer se caen solas, porque no explican por qué empezó el 14 de julio y no antes. La segunda es que la sesión deja de ser una lluvia de ideas y se vuelve una lista de sospechosos con coartada que hay que ir a verificar.
Sin esa línea, el equipo discute opiniones hora y media. Con ella, discute evidencia veinte minutos. Es el mismo grupo, el mismo pizarrón y la misma herramienta.
De la espina a la causa raíz
Cuando el diagrama está lleno viene lo que casi siempre se salta. Eliges las tres o cuatro causas más probables y a cada una le preguntas por qué, encadenado, hasta llegar a algo que dependa del sistema y no de una persona. Si tu respuesta final es un nombre propio, todavía no llegaste.
Cada causa necesita su verificación concreta: una medición, un registro, una prueba de que sí ocurre. Las que no se comprueban se tachan. No se dejan ahí por si acaso, porque una rama sin comprobar es justo la que después justifica una acción que no sirvió y costó dinero.
Tres errores que veo cada mes
- Llenarlo entre puros ingenieros. El operador que hace la pieza ocho horas al día ve causas que nadie más ve. Si no está en la mesa, te faltan la mitad de las ramas.
- Confundir el síntoma con la causa. "Alto rechazo" no va en una rama: ese es el problema. En las ramas va lo que lo produce.
- Dejarlo sin dueño ni fecha. Un diagrama sin responsables y sin día de verificación es un dibujo. Cada causa elegida necesita nombre y fecha.
Dónde encaja esto
El Ishikawa es una pieza dentro de algo más grande. En un 8D vive en la D4. En un A3 ocupa el cuadro del análisis. Si tu planta lo usa suelto, cada quien lo hace distinto y no puedes comparar un problema con otro. Dentro de un método, se vuelve memoria de la organización.
Eso es lo que trabajo con los equipos que acompaño: el sistema que hace que se use igual, se documente igual y no regrese el mismo problema con otro nombre tres meses después.
Empieza por aquí
Toma el problema que más te esté costando ahorita y escríbelo en una línea con los cuatro datos: qué, dónde, desde cuándo, cuánto. Si no puedes completar los cuatro, todavía no tienes un problema definido. Tienes una queja, y ninguna herramienta arregla eso.
¿Cuántas causas debe tener un diagrama de Ishikawa?
No hay número correcto. La prueba es distinta: si ninguna rama te sorprendió, el equipo estaba incompleto o nadie se sintió con permiso de hablar.
¿El Ishikawa da la causa raíz?
No. Ordena las causas candidatas. La causa raíz sale de encadenar porqués sobre las ramas que sobrevivieron a la verificación.
¿Sirve fuera de manufactura?
Sí. Las 6M son la versión de planta. En servicios se cambian las categorías y funciona igual, siempre que el problema esté definido con qué, dónde, desde cuándo y cuánto.