M365Con 2027 – conferencia online gratuita · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Análisis de causa raíz en producción: 5 porqués y diagrama de espina de pescado en la práctica

Por ·

Análisis de causa raíz en producción, paso a paso: cuándo usar los 5 porqués o un diagrama de espina de pescado, cómo verificar una causa y un ejemplo práctico de tiempo de inactividad con cifras.

Traducido automáticamente con IA a partir de la publicación original. Lee el original en inglés

El análisis de causa raíz (RCA) identifica la causa subyacente de un problema, para que la solución evite que vuelva a producirse. En producción, las herramientas habituales son los 5 porqués y el diagrama de espina de pescado. Este artículo está dirigido a responsables de producción que deben resolver hoy los problemas de línea y quieren que queden resueltos. Obtendrás una rutina clara, una guía para elegir entre las dos herramientas, un ejemplo práctico de tiempo de inactividad con cifras y una lista de errores comunes.

Puntos clave

  • El análisis de causa raíz identifica la causa subyacente de un problema para que la solución evite la recurrencia, en lugar de tratar un síntoma.
  • Usa los 5 porqués para una cadena clara de causa y efecto, y un diagrama de espina de pescado primero cuando puedan interactuar varias causas.
  • Cada porqué debe responderse con un hecho observado o un dato medido, no con una hipótesis, y la causa debe verificarse antes de actuar.
  • Empieza por las mayores pérdidas, usando una vista de Pareto, y da prioridad al cuello de botella, donde el tiempo perdido encarece toda la línea.
  • Una solución solo queda demostrada cuando la comprobación confirma que el problema no ha vuelto, así que ejecútala como una pequeña prueba de PDCA.

¿Qué es el análisis de causa raíz en producción?

iSixSigma describe el análisis de causa raíz como una forma de identificar el origen subyacente de un fallo en un proceso o producto. Recomienda empezar por una descripción factual del problema: el producto o proceso fallido, las observaciones, el número de unidades defectuosas y la descripción del cliente's. Consulta su artículo sobre diagramas de Ishikawa y los 5 porqués.

Tres términos se confunden fácilmente:

  • Contención protege al cliente o la línea hoy, por ejemplo separando las piezas sospechosas. No elimina la causa.
  • Acción correctiva es el cambio que elimina la causa.
  • Causa raíz es la causa que, una vez eliminada, evita que el problema se repita en condiciones similares.

Si solo contienes, el mismo defecto o la misma parada volverán. Si pasas directamente a la acción correctiva sin una causa verificada, puedes corregir lo que no es. El análisis de causa raíz está entre ambas.

¿Cuándo usar los 5 porqués?

El glosario de ASQ describe los Cinco porqués como una técnica que consiste en preguntar repetidamente "¿por qué?". Normalmente se aplica unas cinco veces, aunque es aceptable hacerlo más o menos, y atribuye su desarrollo a Sakichi Toyoda. Sus reglas son prácticas:

  1. Redacta una descripción precisa del problema, respaldada por datos.
  2. Pregunta por qué ocurrió el problema y registra la causa observable más cercana.
  3. Sigue preguntando por qué ante cada respuesta, manteniéndote en los hechos.
  4. Detente en una causa sobre la que puedas actuar para evitar la recurrencia.
  5. Verifica la causa raíz: ¿conduce al problema y, si la corriges, evitaría que se produjera?
  6. Aplica una contramedida y confirma mediante una medición de seguimiento que el problema no se repite.

La misma página señala que cada respuesta debe ser "un hecho observado o un dato medido, no una hipótesis". También indica que el método funciona mejor en cadenas causales lineales con una única causa raíz, y recomienda un diagrama de espina de pescado para problemas complejos.

¿Cuándo es mejor un diagrama de espina de pescado?

Un diagrama de espina de pescado, o de Ishikawa, es una representación de hipótesis. El efecto, como "disparos cortos en la prensa 3", se sitúa en la cabeza, y las ramas muestran las posibles causas. Los equipos suelen agrupar las ramas en máquina, método, material, personas, medición y entorno. El diagrama permite al equipo ver muchas posibles causas a la vez y acordar cuáles probar.

iSixSigma recomienda una forma clara de combinar las herramientas: primero, redacta la declaración del problema y recopila datos; después, construye el diagrama a partir de hipótesis que describan efectos observables; aplica los 5 porqués a las ramas más probables y haz seguimiento de cada hipótesis con un responsable y una fecha límite. También advierte de que los diagramas creados mediante lluvia de ideas suelen incluir causas que no contribuyen, y de que las categorías vagas, como "iluminación", rara vez muestran un camino hacia el fallo.

Regla general: si existe una única cadena clara, los 5 porqués son suficientes. Si hay varios factores posibles que contribuyen, o si el equipo no está de acuerdo, primero conviene un diagrama de espina de pescado.

Muchos problemas de producción tienen más de una de las causas raíz en juego. Una parada breve puede deberse a una pieza desgastada, a una comprobación que falta y a una carencia de formación al mismo tiempo. Al identificar la causa raíz, pregúntate si has encontrado una de las causas raíz o todas. Definir bien el problema es la mitad de la respuesta: una declaración precisa, como "paradas en la estación 3 en el turno de noche", conduce a menos causas potenciales que una declaración amplia. Para determinar la causa raíz de un defecto recurrente, compara las series buenas con las malas y anota qué es diferente. Después, implementa acciones correctivas para cada causa verificada, de una en una, para poder ver cuál funciona. Es resolución de problemas en su forma más sencilla: primero los hechos, después las hipótesis y, por último, las acciones.

¿Cómo se aplica el RCA en la línea?

  1. Contener. Protege primero al cliente y la línea. Pon en cuarentena el producto sospechoso y restablece un estado seguro.
  2. Elige el problema. No analices todo. Usa una vista de Pareto, un ranking de pérdidas de mayor a menor, y ataca la más grande. Fíjate primero en el cuello de botella, el paso que limita la producción. Un minuto perdido allí se pierde para toda la línea, mientras que un minuto perdido en un paso con capacidad libre puede no costar nada.
  3. Defínelo con datos. ¿Qué, dónde, cuándo, cuánto y comparado con qué? Pon un número.
  4. Ve y observa. Observa el proceso real en el gemba, la palabra japonesa que significa "el lugar real", la planta de producción. Habla con los operarios que estaban allí.
  5. Encuentra las causas candidatas. Usa los 5 porqués o un diagrama de espina de pescado con un equipo multidisciplinar: operario, mantenimiento, calidad y un supervisor.
  6. Verifica. Prueba la causa probable. Si es real, eliminarla debería cambiar el resultado, y volver a introducirla debería hacer que el problema reaparezca.
  7. Actúa y comprueba. Aplica la contramedida como una prueba pequeña y mide el resultado. El ciclo PDCA da forma a este paso, y un informe A3 puede registrar toda la historia en una sola página.

Ejemplo: tiempo de inactividad en una línea

Este ejemplo usa cifras supuestas.

La línea 4 funciona con dos turnos de 8 horas durante 5 días, es decir, 80 horas planificadas. La semana pasada perdió 14 horas por paradas, lo que equivale a 14 ÷ 80 = 17,5 %.

Pareto de las paradas:

  • Lecturas erróneas del sensor: 6,3 h (45 %)
  • Exceso de tiempo en cambios de formato: 4,2 h (30 %)
  • Espera por material: 2,1 h (15 %)
  • Otras: 1,4 h (10 %)

Las dos causas más grandes suman el 75 % de la pérdida. El equipo empieza por las lecturas erróneas del sensor.

Cinco porqués.

  1. ¿Por qué se detuvo la línea? El sensor leyó mal la posición de la pieza.
  2. ¿Por qué? Había polvo en la lente del sensor.
  3. ¿Por qué había polvo? Nadie limpia la lente durante el turno.
  4. ¿Por qué no? La limpieza no forma parte del trabajo estándar del operario.
  5. ¿Por qué no? El trabajo estándar se escribió antes de instalar el sensor.

La causa raíz es una carencia en el trabajo estándar, no un sensor defectuoso. La contramedida consiste en añadir una revisión de la lente a la rutina de inicio de turno y colocar una pequeña cubierta.

Efecto esperado. Si esto elimina el 80 % de las paradas del sensor: 6,3 × 0,8 = 5,04 horas. El nuevo tiempo de inactividad es 14 − 5,04 = 8,96 horas, o 8,96 ÷ 80 = 11,2 %. La comprobación a las dos semanas muestra si el resultado real coincide. Si no coincide, el equipo vuelve al diagrama.

¿Cómo te aseguras de que la causa es la correcta?

Prueba el hallazgo antes de invertir en una solución. Dos preguntas sencillas ayudan:

  • Si la causa que identificaste fuera otra, ¿el resultado habría sido diferente?
  • Si la eliminas, ¿es poco probable que el mismo fallo se repita en condiciones similares?

Recoge datos antes y después. Un buen RCA termina con un resultado medido y un estándar modificado, y así es como alimenta la mejora continua en lugar de apagar incendios. Anota también los factores contribuyentes que no has corregido, como la formación o las herramientas, para que no se pierdan.

Ten cuidado con el "error humano". Rara vez es una causa raíz. Si un operario cometió un error, pregunta por qué el proceso lo permitió: ¿la instrucción era clara?, ¿la herramienta era adecuada?, ¿había tiempo? La respuesta casi siempre está en el sistema.

Errores comunes

  • Parar en el primer porqué. La primera respuesta suele ser el síntoma.
  • Responder con opiniones. Cada porqué necesita un hecho observado o una medición.
  • Culpar a las personas. La culpa pone fin a la conversación y oculta la causa real.
  • Analizar primero los problemas pequeños. Usa una vista de Pareto y empieza por la pérdida más grande.
  • Omitir la verificación. Una causa no verificada lleva a una solución que no funciona.
  • No cambiar el estándar. Si el trabajo estándar sigue igual, el problema volverá.

Cómo puede ayudar el software

Un buen análisis necesita buenos datos. El software puede registrar el motivo de cada parada en el momento en que ocurre, generar gráficos de Pareto automáticamente y mostrar si un problema vuelve después de la solución. Eso ahorra tiempo en los primeros pasos del RCA y da al equipo hechos en lugar de recuerdos. Una herramienta no piensa por ti. Las personas siguen yendo al gemba y preguntando por qué.

Siguiente paso

Elige la mayor pérdida de la semana pasada en tu línea, redacta una descripción del problema con un número y aplica los 5 porqués con los operarios que estuvieron presentes. Después verifica la causa con una prueba pequeña. Así es como se aplica en la práctica el análisis de causa raíz en tu producción.

Entidades en este artículo

Continuous improvement Bottleneck (production) PDCA cycle (Plan-Do-Check-Act) A3 problem solving

Artículos relacionados

RSS

Patrocinado

iFAKT GmbH