¿Qué es el Diagrama de Ishikawa?

El Diagrama de Ishikawa es una herramienta visual utilizada para organizar e investigar las posibles causas de un problema. Su estructura recuerda al esqueleto de un pescado: en la cabeza colocamos el problema que queremos investigar y, a lo largo de las espinas, distribuimos diferentes grupos de posibles causas.

Precisamente por su formato también se le conoce como diagrama de espina de pescado. Otro nombre muy utilizado es diagrama de causa y efecto, porque su objetivo es relacionar un efecto observado —el problema— con las diferentes causas que pueden estar contribuyendo a que ocurra.

Para mí, una de sus mayores ventajas es que nos obliga a analizar el problema desde una perspectiva más sistémica. En lugar de elegir rápidamente una explicación conveniente, abrimos diferentes líneas de investigación y empezamos a preguntarnos qué procesos, personas, herramientas, información, métodos o condiciones pueden estar contribuyendo al resultado que estamos observando.

Esto es especialmente importante en los proyectos, porque un problema relevante rara vez tiene una única causa aislada. Un retraso puede estar relacionado con estimaciones incorrectas, poca experiencia del equipo, dependencias externas, tareas mal descritas, exceso de trabajo en curso, falta de automatización o varios de estos factores al mismo tiempo.

¿Para qué sirve el Diagrama de Ishikawa?

El Diagrama de Ishikawa puede utilizarse en prácticamente cualquier situación en la que necesitemos comprender por qué está ocurriendo un determinado resultado. En proyectos puede ayudarnos a investigar retrasos, aumentos de costos, problemas de calidad, retrabajo, bugs recurrentes, baja productividad, conflictos entre áreas, fallas de procesos o cualquier otro resultado diferente de lo que habíamos planificado.

No podemos evitarlo: por mucho que planifiquemos un proyecto, eventualmente aparecerá algo que no habíamos mapeado previamente. Cuando estos problemas no se comprenden y resuelven correctamente, pueden generar retrasos en las entregas, retrasos en lanzamientos de productos, problemas con stakeholders, presión sobre los equipos e incluso decisiones más graves relacionadas con personas o presupuesto.

El punto es que resolver el efecto no significa necesariamente resolver la causa. Si las tareas están retrasadas porque el equipo no sabe estimarlas correctamente, aumentar la presión sobre los desarrolladores no corrige el problema. Si la causa está en dependencias mal gestionadas, contratar otra persona puede tampoco resolver nada. El Diagrama de Ishikawa nos ayuda precisamente a abrir estas posibilidades antes de decidir qué acción tomar.

Diagrama de Ishikawa, diagrama de causa y efecto o espina de pescado

Los tres nombres normalmente se refieren a la misma herramienta. Diagrama de Ishikawa es el nombre más asociado a la técnica; diagrama de causa y efecto describe su propósito; y diagrama de espina de pescado describe su apariencia.

Independientemente del nombre utilizado, la lógica es la misma: comenzamos con un efecto que queremos investigar y, a partir de él, organizamos las posibles causas en categorías. Esto nos ayuda a dejar de ver el problema como un único bloque y empezar a entenderlo como un sistema compuesto por diferentes factores que pueden estar relacionados.

¿Cuáles son las 6M del Diagrama de Ishikawa?

Una de las formas más conocidas de organizar las causas dentro de un Diagrama de Ishikawa es utilizando las llamadas 6M. Estas categorías funcionan como una guía para pensar en diferentes posibles orígenes del problema.

• Máquina: equipos, herramientas, sistemas, infraestructura y tecnologías utilizadas.
• Método: procesos, procedimientos, reglas, prácticas e instrucciones de trabajo.
• Material: materias primas, componentes, documentos, información o insumos necesarios.
• Medio ambiente: ambiente físico, organizacional, cultural o condiciones externas que influyen en el trabajo.
• Medición: métricas, inspecciones, sistemas de monitoreo, indicadores y formas de evaluar resultados.
• Mano de obra: personas, experiencia, capacidad, conocimiento, formación y disponibilidad.

Las 6M surgieron en un contexto muy relacionado con calidad e industria, pero su lógica puede adaptarse perfectamente a proyectos de tecnología. “Máquina”, por ejemplo, puede representar herramientas, ambientes, pipelines o infraestructura. “Material” puede representar documentación, requisitos, APIs, componentes o cualquier información necesaria para realizar el trabajo.

Tampoco necesitamos completar obligatoriamente todas las categorías. Si no encontramos una posible causa relacionada con Medición, no debemos inventar una solamente para llenar el diagrama. La herramienta existe para mejorar nuestra investigación, no para completar un template.

Cómo hacer un Diagrama de Ishikawa paso a paso

El primer paso es definir con claridad qué problema queremos investigar. Parece evidente, pero muchos análisis de causa raíz empiezan mal porque el problema inicial fue descrito de manera demasiado vaga.

“El proyecto está mal” no es un problema suficientemente claro. “Las user stories del Equipo X presentan una tasa de retraso de aproximadamente el 20%” ya nos proporciona una base mucho mejor para comenzar.

Después de definir el problema, colocamos ese efecto en la cabeza del pescado. A continuación creamos las categorías que utilizaremos en el análisis —las 6M u otra clasificación más adecuada para nuestro contexto— y comenzamos a incluir posibles causas en cada una de ellas.

En esta etapa intento no buscar una solución demasiado rápido. Primero quiero ampliar la investigación. Puedo hablar con el equipo, analizar datos históricos, revisar procesos, verificar dependencias y construir hipótesis. Después empezamos a eliminar aquello que no encuentra respaldo en los hechos y profundizamos en las causas que parecen más probables.

Ejemplo de Diagrama de Ishikawa aplicado a un proyecto

Imaginemos un problema bastante común: “Todas nuestras tareas están retrasadas.” Si inmediatamente afirmo que la causa es la baja productividad del equipo, estoy saltando directamente del problema hacia una conclusión. El Diagrama de Ishikawa me obliga a abrir la investigación.

Utilizando las 6M, podríamos comenzar con varias hipótesis. En Máquina, podría existir falta de automatización DevOps para realizar deployments en staging y producción. En Método, los refinamientos podrían no estar considerando la experiencia real de los desarrolladores. En Material, quizá nuestros componentes no sean reutilizables. En Mano de obra, tal vez exista un número demasiado alto de desarrolladores junior o falte un profesional DevOps.

Observa que no necesitamos encontrar algo en todas las M. También es posible que una misma causa aparezca en más de una categoría. La falta de experiencia del equipo, por ejemplo, puede aparecer en Mano de obra, pero también puede afectar directamente al Método. La falta de un profesional DevOps puede estar relacionada tanto con Mano de obra como con Máquina, porque también impacta la automatización y la infraestructura.

Cuando una misma causa aparece repetidamente en diferentes partes del análisis, le presto especial atención. Esto no demuestra automáticamente que hayamos encontrado la causa raíz, pero suele ser una señal bastante buena de que deberíamos investigar ese punto con más profundidad.

Cómo encontrar la causa raíz de un problema

El Diagrama de Ishikawa nos ayuda a organizar posibles causas, pero un análisis de causa raíz no debería terminar cuando el diagrama está listo. El siguiente paso consiste en validar qué hipótesis explican realmente el problema.

Si creemos que las tareas se retrasan por falta de experiencia del equipo, necesitamos buscar evidencias. ¿Los profesionales junior realmente tardan más? ¿Qué tipos de tareas presentan una mayor diferencia entre la estimación y la duración real? ¿Los retrasos están concentrados en determinadas áreas? ¿Existe relación con bugs, retrabajo o tareas poco claras?

Si nuestra hipótesis es que los refinamientos tienen poca calidad, podemos analizar cuántas actividades empiezan sin estimación, cuántas son reestimadas después de comenzar, cuántas tienen descripciones insuficientes y cuánto retrabajo aparece durante la ejecución.

Es en este momento cuando dejamos de tener solamente una opinión y empezamos a construir un análisis basado en evidencias.

Cómo utilizar los 5 Porqués para encontrar la causa raíz

La técnica de los 5 Porqués es una de las formas más sencillas de profundizar en una causa que apareció durante el Diagrama de Ishikawa. La lógica consiste en continuar preguntando “¿por qué?” hasta llegar a una explicación más fundamental de lo que está ocurriendo.

A pesar del nombre, no existe ninguna regla que diga que debemos hacer exactamente cinco preguntas. Podemos encontrar la causa en la tercera pregunta o necesitar siete. El objetivo no es alcanzar un número específico, sino continuar avanzando mientras las respuestas sigan describiendo síntomas o consecuencias.

Un ejemplo sencillo:

- ¿Por qué no tenemos acceso a las máquinas de producción?
- Porque el área de seguridad no nos proporcionó el acceso.
- ¿Por qué el área de seguridad no nos proporcionó el acceso?
- Porque solamente el equipo de seguridad puede acceder a producción.
- ¿Por qué solamente el equipo de seguridad puede acceder a producción?

Y aquí quizá lleguemos a aquella respuesta que todos conocen, pero nadie quiere decir:

Porque el CTO lo exigió.

Este ejemplo también muestra una limitación importante de cualquier técnica de análisis de causa raíz: necesitamos transparencia. Si las personas evitan determinadas respuestas porque el problema involucra política, jerarquía o miedo, podemos construir un Diagrama de Ishikawa perfecto y aun así llegar a una conclusión equivocada.

Cómo hacer el ejercicio de los 5 Porqués

Una práctica que considero especialmente útil es construir siempre la siguiente pregunta utilizando la respuesta anterior. Esto crea trazabilidad y reduce el riesgo de empezar a saltar entre hipótesis sin seguir una línea lógica.

Podemos comenzar preguntando: “¿Por qué las tareas están retrasadas?”. La respuesta podría ser: “Porque los desarrolladores están estimando las tareas de forma incorrecta”. La siguiente pregunta debería entonces utilizar exactamente esa respuesta: “¿Por qué los desarrolladores están estimando las tareas de forma incorrecta?”.

Quizá descubramos que existe falta de experiencia, refinamiento insuficiente, requisitos incompletos o una técnica de estimación inadecuada. Cada respuesta crea la siguiente pregunta hasta que llegamos a un punto en el que podemos identificar una acción concreta capaz de tratar el origen del problema.

El Diagrama de Ishikawa y los 5 Porqués funcionan particularmente bien juntos. Ishikawa amplía nuestra investigación y organiza posibilidades. Los 5 Porqués nos permiten profundizar en una de esas posibilidades.

Diagrama de Ishikawa vs. 5 Porqués: ¿cuándo usar cada uno?

No considero que estas técnicas sean competidoras. Resuelven partes diferentes de la investigación. Cuando todavía no sabemos de dónde puede venir el problema, el Diagrama de Ishikawa es especialmente útil porque amplía nuestra visión y organiza diferentes familias de causas.

Cuando ya tenemos una causa candidata y queremos entender qué existe detrás de ella, los 5 Porqués pueden ser más eficientes. Muchas veces empiezo con Ishikawa y después aplico los 5 Porqués sobre una o varias causas que parecen importantes.

En nuestro ejemplo de tareas retrasadas, podríamos identificar “estimaciones incorrectas” dentro del Ishikawa y luego usar los 5 Porqués para investigar por qué las estimaciones están equivocadas. Podríamos hacer exactamente lo mismo con “falta de automatización”, “poca experiencia del equipo” o cualquier otra causa candidata.

La formulación de hipótesis también forma parte del análisis de causa raíz

Antes de confirmar una causa, normalmente estamos trabajando con hipótesis. Para formular buenas hipótesis necesitamos comprender el problema, su contexto, las personas involucradas, los procesos relacionados y la diferencia entre el resultado esperado y aquello que realmente ocurrió.

Una buena hipótesis debería poder investigarse. Decir que “el equipo no está comprometido” es demasiado abstracto. Decir que “el aumento del número de actividades simultáneas está aumentando el tiempo medio de entrega” crea una afirmación que podemos validar.

También podemos utilizar un análisis de escenarios para comprender cómo determinadas causas podrían evolucionar. Imagina que un tech leader está sobrecargado y pide un aumento salarial. El problema puede ser simplemente el salario, pero también puede existir un exceso de responsabilidades, concentración de conocimiento o ausencia de otras personas capaces de asumir sus actividades.

Si esa persona se va de la empresa, podríamos sufrir pérdida de conocimiento, redistribución inesperada del trabajo, insatisfacción del resto del equipo y retrasos en las entregas. Construir estos escenarios ayuda no solamente a investigar el problema, sino también a comprender el riesgo de no hacer nada.

Cuando esta investigación involucra personas con mucho poder o impacto sobre el proyecto, también puede ser importante realizar un buen análisis de stakeholders. Hablo sobre este tema en: Mapa de Stakeholders: cómo crear una matriz, analizar y gestionar stakeholders en un proyecto .

Define bien el problema antes de buscar la causa

Existe un error capaz de comprometer toda la investigación: intentar encontrar la causa raíz de un problema que nunca fue definido correctamente. Si nuestra definición inicial es incorrecta, podemos pasar horas investigando las causas de algo que ni siquiera representa el verdadero problema.

Es aquí donde me gusta utilizar un problem statement. Un problem statement es una declaración clara del problema que queremos resolver. Define qué está ocurriendo, quién está siendo afectado, por qué importa, cuál es la dimensión del problema y qué resultado queremos alcanzar.

Cuanto más podamos cuantificar esta declaración, mejor. En lugar de escribir “nuestras entregas se retrasan demasiado”, podemos llegar a algo como:

“La tasa de retraso en las entregas de user stories del Equipo X es de aproximadamente el 20%, lo que genera cerca de un mes de retraso cada semestre, US$ 100.000 en costos adicionales por semestre e insatisfacción del cliente final, CTO, CEO y área financiera. Las principales causas identificadas son la falta de experiencia del equipo y estimaciones imprecisas. ¿Cómo podemos reducir estos retrasos al 5% en tres meses?”

Ahora tenemos un problema mucho más concreto. Podemos medir si mejoramos, sabemos quién está siendo impactado y podemos conectar la solución con las causas identificadas durante la investigación.

Cómo utilizar los datos del proyecto para validar la causa raíz

Existe una diferencia importante entre una causa posible y una causa respaldada por evidencias. En proyectos de tecnología tenemos la ventaja de producir una enorme cantidad de datos durante la ejecución del trabajo. Jira, Azure DevOps, Asana, Monday.com y ClickUp ya registran actividades, estimaciones, responsables, estados, sprints, fechas, tipos de trabajo y muchas otras informaciones que pueden ser útiles durante una investigación.

Es exactamente aquí donde Saint Jude Project Intelligence puede apoyar este proceso. En lugar de depender únicamente de la percepción del gestor, podemos analizar patrones de retraso, estimaciones incorrectas, performance del equipo, costos, calidad de las actividades, bugs, desviaciones de sprint y riesgos.

Volviendo a nuestro ejemplo de “todas las tareas están retrasadas”, podemos separar el análisis por área, seniority, función, tipo de tarea, tag, costo, horas planificadas, horas consumidas o performance de las sprints. Quizá descubramos que el problema no afecta a todo el equipo, sino solamente a un determinado tipo de actividad. Tal vez los retrasos estén concentrados en tareas sin estimación o en profesionales con determinada seniority.

Esto no sustituye al Diagrama de Ishikawa, los 5 Porqués ni al trabajo del gestor. Al contrario: los datos hacen que estas herramientas sean más fuertes porque nos ayudan a validar o descartar nuestras hipótesis.

La misma lógica se aplica a la productividad. Si nuestra investigación indica que el problema puede estar relacionado con la capacidad o performance del equipo, recomiendo también: Indicadores de productividad: KPI para medir y mejorar la productividad de tu equipo .

Y cuando los retrasos estén relacionados con dependencias y con el impacto de determinadas actividades sobre la fecha final del proyecto, también vale complementar este análisis con: Ruta crítica: cómo identificar dependencias que pueden retrasar tu proyecto .

Encontrar la causa raíz es solamente el comienzo

El Diagrama de Ishikawa nos ayuda a organizar posibles causas. Las 6M nos proporcionan una estructura para explorar diferentes perspectivas. Los 5 Porqués ayudan a profundizar una línea de investigación. La formulación de hipótesis y el análisis de escenarios amplían nuestra comprensión, mientras que un buen problem statement transforma aquello que descubrimos en un problema claro y medible.

Pero ninguna de estas herramientas debería utilizarse solamente para producir un dibujo bonito o completar una planilla. El objetivo final es salir de una discusión basada en síntomas y llegar a una explicación suficientemente sólida como para orientar una decisión.

Si mis tareas están retrasadas, no quiero saber solamente cuántas están retrasadas. Quiero entender por qué están retrasadas. Si mis costos aumentaron, no quiero solamente reducir gastos; quiero descubrir qué está consumiendo más dinero de lo esperado. Si la productividad cayó, quiero entender qué cambió en el sistema antes de concluir simplemente que las personas están trabajando menos.

Después de encontrar la causa raíz, finalmente podemos empezar a discutir soluciones. Hablo específicamente sobre esta siguiente etapa en: Cómo encontrar las soluciones correctas para los problemas de tu producto .

Al final, quizá esta sea la mayor contribución del Diagrama de Ishikawa: nos obliga a dejar de preguntar solamente “¿cómo resolvemos esto?” y comenzar por una pregunta mucho más importante:

“¿Por qué está ocurriendo esto?”

¡Hasta pronto!

Erik Scaranello