En LinGo trabajamos con una lógica distinta: antes de listar causas, entiende el flujo completo del proceso. El diagrama de flujo no reemplaza al Ishikawa; lo pone en su lugar correcto. Primero se observa, se entiende y se detectan fricciones reales. Luego, si hace falta, se profundiza con herramientas como Pareto, 5 porqués o Ishikawa, pero sobre un problema específico, no sobre un problema general.
El error común: empezar por Ishikawa sin ser dueño del proceso
Un Ishikawa puede ser útil, pero tiene una condición: quien lo construye debe conocer el proceso con suficiente detalle. En la práctica, muchos tesistas no son dueños del proceso. Están analizando un área donde no trabajan directamente o donde no dominan cada decisión, cada excepción y cada re-trabajo.
Ahí aparece el gran riesgo: el Ishikawa termina siendo un dibujo “correcto”, pero vacío. Suena lógico en papel, pero no explica la operación real. Y cuando el jurado pregunta “¿cómo sabes que esta es la causa raíz?”, el alumno se queda sin respaldo.
El diagrama de flujo, en cambio, obliga a entrar al terreno correcto: qué pasa primero, qué pasa después, quién lo hace, qué información entra, qué información sale y dónde se generan las esperas. Cuando dibujas el proceso paso a paso, las oportunidades de mejora dejan de ser ideas bonitas y se convierten en hipótesis observables.
El diagrama de flujo como herramienta de “ingenio”: qué preguntas dispara
La diferencia clave entre un Ishikawa y un diagrama de flujo es el tipo de preguntas que generan.
El Ishikawa te empuja a listar causas por categorías. El diagrama de flujo te empuja a cuestionar el diseño del proceso con preguntas de ingeniería: por qué esto ocurre aquí, para qué existe este paso, qué pasaría si lo elimino, por qué hay una condición, por qué alguien revisa esto y luego otra persona vuelve a revisarlo.
En un proceso de postventa, por ejemplo, basta mapear el inicio (ingreso de solicitud) para detectar fricciones. Si la solicitud llega por un canal genérico y se mezcla con correos que no son devoluciones, una parte del tiempo se va en clasificar, filtrar y “limpiar” bandejas. Ese desperdicio no aparece en un Ishikawa si nadie lo mide. Pero el flujo lo hace visible.
Y aquí entra una idea poderosa: lo que parece “poco” (como 30 minutos al día revisando correos innecesarios) se vuelve enorme al año. Es el tipo de desperdicio que muchas empresas no ven porque no lo miden; pero el análisis de procesos sí lo captura.
Cómo evitar el error de “ramificar” oportunidades y perder foco
Otro problema típico en tesis es detectar muchas oportunidades y querer arreglarlo todo. En postventa, por ejemplo, es fácil encontrar mejoras en la cotización, en la orden, en la comunicación con el cliente, en stock, en logística inversa, en aprobaciones, etc. Pero una tesis no es una consultoría completa.
Aquí entra el secreto que casi nadie aplica bien: delimitación.
Delimitar no es “hacer menos”. Delimitar es elegir el punto donde el impacto es alto y la medición es viable. Una tesis sólida no es la que intenta mejorar todo el proceso; es la que mejora una parte crítica, la mide correctamente y demuestra resultados.
Esto aplica también al uso de Pareto. Si existen tres tipos de casos (devoluciones, reclamos y garantías), la tesis no debería abarcar todo solo por “variabilidad”. En servicio, la variabilidad excesiva destruye la capacidad de medir. Si una devolución consume horas muy distintas a un reclamo, comparar productividad como si fueran iguales genera ruido estadístico.
En términos simples: si mezclas peras con manzanas, luego no puedes demostrar mejora con claridad. Por eso conviene identificar cuál caso domina (por volumen, impacto o tiempo) y enfocar ahí el rediseño. Las mejoras aplicadas a ese caso suelen ser transferibles a los otros, pero tu investigación debe ser defendible y medible.
Productividad en servicios: el error de medir como si fuera producción
Uno de los choques más grandes entre lo teórico y lo práctico aparece cuando un asesor pretende medir productividad en servicio igual que en producción. En postventa no “produces unidades”; gestionas solicitudes que consumen tiempos y recursos distintos.
Por eso, en muchos casos resulta más defendible medir productividad a nivel de semanas de atención y no por solicitud individual. Medir por semana permite responder preguntas básicas con claridad: cuántas solicitudes ingresaron, cuántas se resolvieron, cuántas quedaron pendientes y qué tan cerca se estuvo del objetivo.
Ese enfoque reduce el ruido y permite evaluar antes y después de una mejora con mayor coherencia, especialmente cuando la empresa no mide productividad de manera formal por solicitud.
Cómo se conecta todo esto con la sustentación
La sustentación se gana antes de llegar a la sala. Se gana cuando tu metodología es coherente y cuando el jurado percibe que tú entiendes el proceso. Si tu investigación inicia con un flujo bien levantado, con preguntas reales y con una delimitación clara, el jurado hará menos preguntas porque no quiere exponerse a que el tesista lo deje mal parado con dominio del tema.
La tesis no se trata de llenar hojas. Se trata de preparar respuestas sólidas.
El Ishikawa por sí solo no prepara esas respuestas si no hay proceso entendido. El diagrama de flujo sí, porque te obliga a comprender y a justificar cada intervención.
Conclusión
El Ishikawa no es malo, pero no debería ser el punto de partida automático. En tesis aplicadas de mejora de procesos, especialmente en servicios como postventa, el primer paso debería ser entender el proceso extremo a extremo con un diagrama de flujo. A partir de ahí, las oportunidades aparecen con claridad, la delimitación se vuelve posible y las herramientas como Pareto y 5 porqués se usan donde realmente aportan.
Eso es lo que convierte una tesis en aprendizaje real: pasar de “dibujar herramientas” a “entender procesos y tomar decisiones con evidencia”.
Fuente
Artículo desarrollado a partir del análisis de asesorías de tesis realizadas en el programa de LinGo Consulting, con fines educativos y formativos.
