Diagrama de Ishikawa para startups: cómo encontrar la causa real de tus problemas operativos

Tu startup lleva tres semanas con el mismo problema. Los clientes se activan tarde, el equipo señala en direcciones distintas y cada reunión termina igual: con una lista de culpables y ninguna solución real.

El problema no es que tu equipo sea malo diagnosticando. Es que estáis usando el instrumento equivocado.

Hay una herramienta que los equipos de calidad industrial llevan décadas usando para encontrar causas raíz. Se llama diagrama de Ishikawa, o diagrama de espina de pescado. Y si la adaptas bien al contexto de una startup, cambia completamente cómo diagnosticas lo que falla en tus operaciones.

Lo que vas a aprender en este artículo:

• Qué es el diagrama de Ishikawa y por qué las versiones estándar no sirven para startups

• Por qué las 6M de manufactura no encajan con la realidad de un equipo de 5 a 50 personas

• Las 6 categorías operativas que Ebägurin usa cuando adapta Ishikawa a startups early-stage

• Cómo aplicar el análisis completo con un ejemplo real: "los clientes tardan 2 semanas en activarse"

• Un template directo para que lo uses hoy en tu próxima reunión de diagnóstico

Qué es el diagrama de Ishikawa y para qué sirve

El diagrama de Ishikawa es una herramienta de análisis visual que ayuda a identificar las causas raíz de un problema, en lugar de quedarse en sus síntomas. Lo desarrolló el químico e ingeniero japonés Kaoru Ishikawa en los años 60 para gestionar la calidad en procesos industriales. Su forma recuerda a la espina de un pescado: el problema va a la derecha (la cabeza), y las causas potenciales se ramifican hacia la izquierda como espinas de un hueso.

La lógica detrás es sencilla y poderosa. Cuando algo falla, la reacción habitual es señalar lo más visible: "el equipo de ventas no está siguiendo el proceso", "la herramienta no funciona", "alguien no hizo su parte". Ishikawa obliga a ir más atrás. A preguntar no solo qué salió mal, sino por qué, y por qué detrás del por qué.

"Un problema operativo sin causa raíz identificada no es un problema resuelto. Es un problema pospuesto."

El análisis de causa raíz con Ishikawa funciona así en la práctica: defines el efecto (el problema concreto que quieres entender), identificas las grandes categorías donde pueden estar las causas, y para cada categoría vas desgranando hipótesis hasta llegar a algo accionable.

El resultado es un mapa visual donde se ve de golpe dónde se acumula la fricción. No un Excel con 40 tareas de mejora. Un mapa.

Por qué las 6M de manufactura no sirven en startups

Cuando buscas "diagrama Ishikawa" en Google, todo lo que encuentras está pensado para entornos de fabricación industrial. El framework estándar organiza las causas en seis categorías que se conocen como las 6M: Máquina, Material, Mano de obra, Método, Medición y Medio ambiente.

Tiene mucho sentido si estás analizando por qué la línea de producción de una fábrica tiene un 3% de piezas defectuosas.

No tiene ningún sentido si estás intentando entender por qué tu onboarding tarda el doble de lo que debería, por qué nadie mira el dashboard que montaste hace tres meses, o por qué dos personas del equipo hacen exactamente lo mismo sin saberlo.

Las categorías de manufactura asumen que tienes máquinas, materias primas físicas y procesos de producción repetibles con varianza medible. Una startup en fase seed o early-stage trabaja con conocimiento, decisiones, herramientas digitales y personas. La "Máquina" no aplica. El "Material" no aplica. Y el "Medio ambiente" como categoría de calidad industrial tampoco.

Si intentas forzar el análisis de causa raíz de tu startup dentro de las 6M, terminas o vaciando las categorías de contenido, o metiendo todo en "Mano de obra" porque es la única que parece relevante. Y cuando todo cae en "Mano de obra", el diagnóstico siempre apunta a personas. Que es el diagnóstico más cómodo y el más equivocado la mayoría de las veces.

"Si nadie en tu equipo sabe quién hace qué, no tienes un problema de personas. Tienes un problema de procesos."

Lo que necesitas no es otra versión del Ishikawa de manufactura con los nombres cambiados. Necesitas unas categorías que reflejen cómo funciona realmente una startup operativamente.

Las 6 áreas operativas de Ebägurin para startups

Cuando entramos en una startup a hacer un diagnóstico operativo, usamos un conjunto de categorías que hemos ido afinando a partir de los problemas reales que nos encontramos. No son las 6M. Son las 6 áreas donde los problemas operativos de startups early-stage tienen su origen casi siempre.

Las llamamos las 6 áreas operativas para el análisis de causa raíz en startups:

1. Personas

Incluye todo lo relacionado con el equipo: claridad de roles, nivel de experiencia para la tarea, carga de trabajo real, alineación con el objetivo, motivación. Pero también, y esto es importante, la estructura de responsabilidades: quién decide qué, quién tiene que ser consultado, quién ejecuta.

Esta categoría no es "la culpa es de alguien". Es la pregunta: ¿el equipo tiene lo que necesita para hacer bien esto?

Lo que se explora aquí: ¿Hay un responsable claro? ¿Esa persona tiene la información y los recursos necesarios? ¿Tiene demasiadas cosas encima? ¿Entiende el objetivo final de la tarea, o solo el paso que le toca?

2. Procesos

Todo lo que tiene que ver con cómo está definido el flujo de trabajo: si existe documentado, si se sigue, si es realista para el contexto de la startup, si tiene lagunas o pasos redundantes.

La mayoría de los problemas que parecen de personas son realmente de proceso. Alguien no hizo algo porque no había un proceso claro que le indicara cuándo, cómo y con qué información hacerlo.

Lo que se explora aquí: ¿Existe un proceso documentado? ¿Se sigue en la práctica? ¿Dónde se rompe? ¿Hay pasos que dependen de la memoria de alguien en lugar de de un sistema?

En nuestros diagnósticos operativos, en más de 7 de cada 10 casos el problema que el founder describe como "de personas" tiene su causa raíz en un proceso que no existe o que nadie ha comunicado correctamente.

3. Herramientas

El stack tecnológico: qué herramientas se usan, cómo están configuradas, si están integradas entre sí, si el equipo las usa de verdad o las evita. También si la herramienta correcta existe o si el equipo está usando un workaround de otra cosa porque nadie ha tomado la decisión de adoptar lo adecuado.

Lo que se explora aquí: ¿La herramienta existe? ¿Está bien configurada para este proceso? ¿El equipo sabe usarla? ¿Los datos fluyen automáticamente o alguien tiene que copiarlos a mano? ¿Hay duplicidad de herramientas que genera confusión?

Si quieres entender cómo funciona el stack operativo mínimo viable para startups en cada fase de crecimiento, tienes una guía completa donde desglosamos herramienta a herramienta qué necesitas y cuándo.

4. Datos

La información disponible para tomar decisiones: si existe, si es fiable, si llega a quien la necesita y cuándo la necesita. Incluye dashboards, métricas de producto, CRM, reportes internos.

Esta categoría es más relevante de lo que parece en startups early-stage. Muchos problemas operativos tienen su origen en que las decisiones se toman sin información o con información incorrecta, no porque el equipo sea negligente, sino porque el dato no existía o llegaba tarde.

Lo que se explora aquí: ¿Existe el dato que se necesita para tomar esta decisión? ¿Quién lo genera? ¿Con qué frecuencia se actualiza? ¿Llega a quien lo necesita o hay que ir a buscarlo? ¿Es fiable?

5. Comunicación

Cómo fluye la información dentro del equipo: entre fundadores y equipo, entre áreas, entre el equipo interno y clientes o partners. Incluye canales, frecuencia, formato y si los mensajes importantes llegan con suficiente contexto.

Esta es la categoría que más se subestima y que más daño hace en silencio. Un proceso puede ser perfecto sobre el papel y romperse completamente porque la información relevante no llega a quien la necesita a tiempo.

Lo que se explora aquí: ¿Quién comunica qué a quién y cuándo? ¿Hay canales claros o todo va mezclado en el mismo Slack? ¿Las decisiones se comunican hacia abajo o solo se ejecutan? ¿Los clientes reciben información proactiva o tienen que preguntar?

6. Prioridades

Qué el equipo decide atender primero y por qué. Incluye si hay un sistema claro de priorización, si los OKRs o el roadmap están definidos y comunicados, si las urgencias del día a día desplazan constantemente el trabajo estratégico.

En una startup early-stage, las prioridades mal gestionadas son probablemente la fuente de caos más frecuente. Si tu equipo trabaja siempre en lo urgente y nunca en lo importante, el problema no es de disciplina: es de que no hay un sistema que proteja las prioridades reales.

Herramientas como la matriz de Eisenhower para founders ayudan a estructurar estas decisiones cuando el volumen de tareas supera lo que una persona puede gestionar mentalmente.

Lo que se explora aquí: ¿Hay un sistema de priorización claro? ¿El equipo sabe qué es lo más importante esta semana? ¿Las urgencias tienen un proceso de triage o interrumpen todo por defecto? ¿El trabajo importante avanza aunque no sea urgente?

Cómo construir el diagrama: guía paso a paso

Paso 1: Define el problema con precisión

Antes de dibujar nada, necesitas definir el problema de forma específica y medible. No "el onboarding va mal". Sí: "los clientes tardan una media de 14 días en completar el onboarding cuando el objetivo es 7 días".

La diferencia importa. Una definición vaga genera causas vagas. Una definición precisa permite encontrar causas concretas y accionables.

Escribe el problema en una frase corta y ponla a la derecha de tu hoja o de tu herramienta. Esa es la cabeza del pescado.

Paso 2: Dibuja la espina central y las 6 ramas

Desde el problema, traza una línea horizontal hacia la izquierda (la espina dorsal). Añade seis ramas diagonales, tres arriba y tres abajo, con las etiquetas de las 6 áreas: Personas, Procesos, Herramientas, Datos, Comunicación, Prioridades.

Puedes hacer esto en papel, en una pizarra, en Figma, en Miro, en Notion. La herramienta no importa. Lo que importa es que sea visible para todo el equipo mientras trabajáis.

Paso 3: Brainstorming de causas por área

Con el equipo, y para cada área, preguntad: ¿qué podría estar causando este problema desde esta categoría? No filtréis en este momento. Apuntad todo.

Ejemplos para el problema "los clientes tardan 14 días en activarse":

Personas: ¿Hay alguien responsable del onboarding de cada cliente? ¿Esa persona tiene suficiente tiempo? ¿Tiene toda la información del cliente antes de empezar?

Procesos: ¿Existe un proceso de onboarding documentado? ¿Tiene pasos claros con tiempos definidos? ¿Hay dependencias que nadie gestiona activamente?

Herramientas: ¿Hay una herramienta que gestione el estado del onboarding? ¿El cliente tiene acceso claro a lo que necesita? ¿Los recordatorios son automáticos o manuales?

Datos: ¿Sabemos en qué paso se atascan los clientes? ¿Medimos el tiempo de cada etapa? ¿Tenemos visibility de qué clientes están activos, parados o en riesgo?

Comunicación: ¿Quién comunica al cliente qué esperar y cuándo? ¿Hay comunicaciones proactivas o solo reactivas? ¿El cliente sabe en todo momento cuál es el siguiente paso?

Prioridades: ¿El onboarding compite con otras tareas del mismo equipo? ¿Cuando hay una incidencia, el onboarding de clientes nuevos se paraliza?

Paso 4: Profundiza con "¿por qué?"

Para cada causa que parezca relevante, aplica la técnica de los 5 porqués: sigue preguntando "¿y por qué ocurre esto?" hasta que llegues a algo que puedas cambiar.

Un ejemplo completo:

Causa inicial: Los clientes no saben cuál es el siguiente paso en el onboarding.

¿Por qué? Porque nadie les envía un resumen de próximos pasos después de la primera sesión.

¿Por qué? Porque no existe una plantilla ni un protocolo para hacerlo.

¿Por qué? Porque el proceso de onboarding nunca se documentó; cada persona que hace onboarding lo hace a su manera.

Causa raíz: No existe un proceso de onboarding estandarizado ni documentado.

Ahí ya tienes algo accionable. No "mejorar la comunicación con el cliente" (vago), sino "documentar el proceso de onboarding y crear una plantilla de resumen de próximos pasos para enviar tras cada sesión" (específico, asignable, medible).

Paso 5: Prioriza las causas raíz

Después del brainstorming, tendrás un mapa con muchas causas potenciales. No todas tienen el mismo peso. Prioriza usando dos criterios simples:

• Impacto: ¿Cuánto contribuye esta causa al problema?

• Control: ¿Podemos actuar sobre esta causa ahora, con los recursos que tenemos?

Las causas de alto impacto y alto control son las que atacas primero. Las de alto impacto y bajo control requieren un plan diferente (recursos, decisiones estratégicas, tiempo). Las de bajo impacto, las dejas para después o las descartas.

Paso 6: Convierte causas en acciones

Cada causa raíz priorizada se convierte en una acción concreta con responsable, plazo y criterio de éxito. Sin esta conversión, el Ishikawa es un ejercicio bonito que no cambia nada.

Formato mínimo para cada acción:

• Qué: [acción específica]

• Quién: [persona responsable, no "el equipo"]

• Cuándo: [fecha o sprint concreto]

• Cómo sabemos que funcionó: [métrica o resultado observable]

Ejemplo completo: "los clientes tardan 2 semanas en activarse"

Vamos a llevar el análisis de principio a fin con un caso concreto basado en un patrón que vemos con frecuencia en startups B2B con las que trabajamos.

El problema: Una startup SaaS B2B de 12 personas con 40 clientes activos detecta que el tiempo medio de activación (desde firma del contrato hasta primer uso real del producto) es de 14 días. El objetivo era 7 días. El churn en los primeros 60 días está por encima del benchmark del sector.

El brainstorming por área:

Personas:

• No hay un "onboarding manager" definido; lo hace quien tiene hueco

• El CSM no recibe el contrato firmado hasta 2-3 días después de que ventas lo cierra

• El equipo técnico que configura el entorno del cliente tiene otras prioridades activas

Procesos:

• No existe un checklist de onboarding documentado

• La activación del cliente requiere pasos que dependen de 3 equipos distintos sin coordinación formal

• No hay un criterio definido de qué significa "cliente activado"

Herramientas:

• El estado del onboarding se gestiona en un Google Sheet manual que nadie actualiza consistentemente

• El cliente accede al producto por primera vez sin una guía o flujo de bienvenida dentro de la app

• No hay automatización de recordatorios para pasos pendientes

Datos:

• No hay visibilidad en tiempo real de en qué paso está cada cliente

• No se mide el tiempo de cada etapa del onboarding

• El equipo no sabe qué paso genera más abandono o retraso

Comunicación:

• El cliente no recibe comunicación proactiva; solo cuando pregunta

• La información del cliente no pasa formalmente de ventas a customer success

• No hay una comunicación estándar de "bienvenida" con expectativas claras

Prioridades:

• Cuando hay una incidencia de un cliente existente, el onboarding de nuevos clientes se detiene sin protocolo claro

• El equipo técnico prioriza el desarrollo de producto sobre la configuración de entornos de nuevos clientes

Causas raíz identificadas (alta prioridad):

1. No existe un proceso de onboarding documentado ni un responsable único por cada cliente.

2. No hay visibilidad del estado de cada onboarding, lo que hace imposible detectar bloqueos a tiempo.

3. El traspaso entre ventas y customer success no tiene un protocolo formal.

Acciones resultantes:

1. Documentar el proceso de onboarding completo en una página de Notion, con propietario (CSM asignado), pasos, tiempos objetivo y criterio de activación. Responsable: Head of Customer Success. Plazo: 2 semanas.

2. Crear un tracker de onboarding en HubSpot con etapas definidas y alerta automática si un cliente lleva más de 48h sin avance en un paso. Responsable: Ops + CSM. Plazo: 3 semanas.

3. Definir un protocolo de handoff ventas → CSM: reunión de traspaso de 30 minutos con ficha del cliente el mismo día de la firma. Responsable: Sales + CSM. Plazo: inmediato (proceso manual hasta que se automatice).

Criterio de éxito: Reducir el tiempo medio de activación de 14 a 8 días en 60 días tras implementar los cambios. Medir churn en primeros 60 días en el siguiente trimestre.

Cuándo usar el Ishikawa y cuándo no

El diagrama de Ishikawa es una herramienta de diagnóstico, no una herramienta de gestión del día a día. Úsala cuando:

• Un problema operativo se repite y no sabes por qué

• El equipo tiene hipótesis distintas sobre la causa y necesitáis alinearos

• Quieres hacer un diagnóstico riguroso antes de implementar cambios

• Estás haciendo una sesión de retrospectiva después de un fallo importante

No la uses cuando:

• El problema es urgente y necesitas una solución ahora (primero apaga el fuego, luego analiza la causa)

• Ya sabes la causa raíz con certeza y solo necesitas ejecutar

• El equipo es de 2-3 personas y la respuesta es obvia para todos

La deuda operativa que se acumula en una startup early-stage es exactamente el tipo de problema que el Ishikawa ayuda a desenredar: múltiples causas interrelacionadas que se manifiestan como un único síntoma visible. Si quieres entender en profundidad cómo funciona la operativa de una startup a medida que crece, en nuestra guía de operaciones para startups de 2 a 50 personas encontrarás el marco completo de cómo estructurar cada fase.

Errores comunes al usar Ishikawa en startups

Definir el problema de forma demasiado amplia. "El equipo no está alineado" no es un problema analizable con Ishikawa. "El equipo de ventas y el de producto tienen objetivos contradictorios en Q3, lo que está generando fricción en la priorización del roadmap" sí lo es.

Quedarse en los síntomas. Si tu causa raíz es "el equipo no hace seguimiento", sigue preguntando. ¿Por qué no hace seguimiento? ¿No sabe que tiene que hacerlo? ¿No tiene tiempo? ¿No tiene la herramienta adecuada? Hasta que no llegas a algo que puedas cambiar, no has llegado a la causa raíz.

Hacer el análisis sin el equipo. El Ishikawa es una herramienta de trabajo colectivo. Cuando el founder lo hace solo en su cabeza, el diagnóstico refleja su visión parcial del problema. Las personas que ejecutan los procesos tienen información que el founder no tiene.

No convertir el análisis en acciones. El diagrama es solo el mapa. El trabajo real es lo que viene después: priorizar causas, asignar responsables y ejecutar cambios. Un Ishikawa sin plan de acción es un ejercicio que se archiva y se olvida.

Usar las 6M de manufactura. Ya lo hemos explicado, pero merece repetirse. Si no estás fabricando piezas físicas, las categorías de manufactura van a distorsionar tu análisis. Adapta las categorías a tu contexto.

Template: cómo estructurarlo para tu startup

Si quieres aplicar esto directamente, aquí tienes la estructura mínima que puedes replicar en una pizarra, en Miro o en un Google Doc:

Problema (cabeza del pescado): [Escribe el problema en una frase específica y medible]

Ramas (una por área):

Sesión recomendada:

• Participantes: founder + las personas que ejecutan el proceso afectado

• Duración: 60-90 minutos

• Formato: primero brainstorming libre por área (20 min), luego profundización en las causas más relevantes con 5 porqués (30 min), luego priorización y plan de acción (20 min)

"Automatizar el caos solo te da caos más rápido."

Si antes de montar ningún sistema nuevo no tienes claro cuál es la causa raíz de lo que está fallando, lo que estás construyendo es una solución al síntoma. Que se volverá a manifestar de otra forma en tres meses.

¿Tienes un problema operativo que tu equipo lleva semanas debatiendo sin resolución? Muchas veces el problema no es falta de esfuerzo, sino falta de método para llegar a la causa real. En el Plan Diagnóstico Express de Ebägurin hacemos exactamente eso: en 1-2 semanas mapeamos qué funciona, qué falla y dónde están las causas raíz de los problemas que están frenando tu crecimiento.

Hablemos sobre tu startup →