Cómo crear un diagrama de flujo de análisis de causa raíz
Cómo dibujar un diagrama de flujo de análisis de causa raíz que elija la técnica por ti: el control de evidencia que precede a todo método, la rama que separa una cadena de varias y dónde se detiene cada método.
Un diagrama de flujo de análisis de causa raíz es un árbol de decisión que lleva al investigador a la técnica que la evidencia disponible puede sostener de verdad (los 5 porqués, un Ishikawa, un árbol de fallos) y que dice dónde se detiene cada una.
En resumen
- Una sola salida: la técnica que hay que abrir, no un relato de la investigación.
- Los 5 porqués asumen una única cadena y fallan en silencio en cuanto hay más de una.
- Tira de un Ishikawa cuando la causa podría estar en cualquiera de varias categorías.
- Un árbol de fallos solo compensa su coste cuando varias condiciones tuvieron que coincidir.
- Nombrar a una persona es donde un análisis se detuvo pronto, no donde terminó.
Un selector de método, no un diario de investigación
Busca un diagrama de flujo de análisis de causa raíz y casi todo lo que aparece es un diario de investigación: definir, recopilar, analizar, verificar, actuar. Es exacto y es inútil, porque nadie se ha atascado nunca en el orden de esas cinco palabras. En lo que se atascan los investigadores es en qué técnica abrir, y un diagrama que no contesta a eso ha dibujado la mitad fácil del trabajo.
Aplica los 5 porqués a un fallo que necesitó tres condiciones a la vez y seguirá produciendo cinco líneas bien ordenadas: equivocadas, seguras de sí mismas y ya escritas. Un Ishikawa asume categorías y no puede expresar dependencia; un árbol de fallos expresa dependencia pero necesita un evento superior definido. Por eso hay una rama que tiene que ir por delante de las tres: ¿la evidencia describe una sola cadena de sucesos o varias causas candidatas? Ponla ahí y la técnica deja de ser cuestión de gustos.
El ejemplo de abajo decide más de lo que narra: nueve de sus diecinueve filas son preguntas y tres de sus cuatro finales se quedan sin causa. Las flechas que importan van hacia atrás. «¿Se llegó a una causa controlable?» manda una cadena que se ha abierto de vuelta a «Mapear causas en un Ishikawa» (admitir a mitad del análisis que el método era el equivocado) y «¿Se puede obtener más evidencia?» vuelve a «Recopilar registros y entrevistas» en lugar de dejar que una hipótesis se archive como hallazgo.
De la evidencia al método elegido
Cinco fases, y no se elige ninguna técnica antes de la tercera: fíjate en cómo «¿Naturaleza del fallo?» reparte «Técnico», «Humano» y «Sistémico» entre tres métodos distintos.
Enmarcar es un bucle, no un paso
Tres filas, y el árbol todavía no ha empezado: «¿El problema está bien definido?» rechaza un enunciado hasta que «Acotar el enunciado del problema» lo ha estrechado. Todas las elecciones posteriores se hacen desde esa redacción, así que un enunciado que nombra una causa sospechada ya ha elegido el método antes de leer ninguna evidencia.
Evidencia antes que técnica
Todavía no se ha elegido nada: «¿Ya hay evidencia disponible?» y «¿Datos suficientes para analizar?» están por delante de todas las cajas de método. La salida «Insuficientes» aterriza en «Volver a la recopilación de evidencia», porque una secuencia que nadie puede reconstruir no puede decir si hay una cadena o varias categorías en juego.
La fila que elige el método
Primero la estructura: «¿Evento único o recurrente?» lleva a «¿Naturaleza del fallo?», cuyas tres salidas son todo el asunto: «Técnico» a «Construir un árbol de fallos», «Humano» a «Aplicar los 5 porqués a la cadena» y «Sistémico» a «Mapear causas en un Ishikawa». Lo recurrente va directo al Ishikawa.
Dos finales que no son una causa
La verificación termina de tres maneras y dos de ellas no son una causa. «¿Se puede obtener más evidencia?» acaba por «Agotada» en «Cerrar con limitación de datos», donde ya no se cumple la prueba de entrada de ninguna técnica; «¿Causa bajo control local?» acaba por «Fuera del ámbito» en «Escalar a investigación formal».
Cómo funciona
Lista los métodos que tu equipo sabe ejecutar
Escribe las cuatro o cinco técnicas en las que aquí hay alguien formado (5 porqués, Ishikawa, árbol de fallos, análisis de cambios, AMFE) con una frase sobre la evidencia que exige cada una. Un árbol de decisión que termina en un método que nadie sabe ejecutar es una derivación a un desconocido, y lo van a ignorar.
Escribe la prueba de entrada de cada método
Enuncia la condición que selecciona cada técnica: una secuencia reconstruible para los 5 porqués, varias categorías plausibles para un Ishikawa, condiciones que tuvieron que coincidir para un árbol de fallos, funcionaba ayer y hoy no para el análisis de cambios. Esas condiciones se convierten en los rombos, así que tienen que ser comprobables y no cuestión de gusto.
Escribe las preguntas como filas y las respuestas como ramas
Cada rombo es una fila: la pregunta en «Box text», Decision en la columna «Shape», los números de fila de destino en «Line to» y las respuestas en «Line text» en el mismo orden. La fila de tres salidas lleva tres números y tres etiquetas, y el diagrama se vuelve ilegible en el momento en que esas dos listas se descuadran.
Da a cada fila de método una regla de parada
Una caja que solo dice que ejecutes la técnica se ejecutará hasta que el investigador se aburra. Pon la condición de parada en el campo de comentarios del paso (la última causa que esta organización puede cambiar) y dibuja una decisión justo detrás, para que una cadena que se abre tenga adónde ser enviada.
Dibuja los dos finales que no son hallazgos
Un árbol que funciona necesita una salida para la evidencia que se agotó y otra para una causa fuera del control local. Pon la columna «Shape» en Reject en la primera y en End en la segunda. Sin la primera, un investigador cuyos registros han desaparecido ejecuta igualmente la técnica más cercana con su prueba de entrada incumplida, que es justo el desenlace que un selector existe para evitar.
Pruébalo contra tres investigaciones cerradas
Coge tres análisis cerrados, recorre el árbol con cada uno desde su enunciado del problema y mira si aterriza en la técnica que se usó de verdad. Donde no lo haga, decide cuál de los dos estaba mal antes de cambiar ninguno: una prueba de entrada que enruta mal un caso es un defecto del árbol, y un caso que tomó el método equivocado es una investigación que hay que reabrir.
Errores que debes evitar
5 porqués en un fallo multicausa
La técnica no puede representar dos condiciones que tenían que estar presentes las dos, así que elige una en silencio y la sigue. Lo que sale es una única cadena que se lee de forma convincente y que elimina una parte de la causa.
Elegir la técnica primero
El método llega con quien fue asignado, y la evidencia se lee después para que encaje con él. Mantén las preguntas de suficiencia y de estructura por delante de todas las cajas de método, para que sean los hechos los que elijan.
Detenerse en el nombre de una persona
Un análisis que termina con alguien ejecutando una tarea de forma incorrecta ha encontrado el último suceso, no la causa. Pregunta qué hizo probable esa ejecución: la instrucción, la disposición del puesto, la carga de trabajo, el relevo.
Abrir un método sin criterio de salida
Sin una regla de parada declarada, una cadena de porqués acaba en filosofía o en culpas, y un Ishikawa se convierte en la lista de todo lo que a cualquiera le disgusta del proceso. Escribe la regla en el propio paso.
Construye tu propio árbol de decisión de causa raíz
Abre el árbol de decisión de método como diagrama propio y fija las pruebas que usan tus investigadores para elegir entre técnicas.
Guías relacionadas
Preguntas frecuentes
¿Qué método de análisis de causa raíz debería usar?
Depende de la forma de la evidencia, y por eso la elección corresponde a un árbol de decisión y no a una política. Un fallo único con una secuencia reconstruible encaja con los 5 porqués. Un problema recurrente cuya causa podría estar en materiales, método, máquina o personas encaja con un Ishikawa. Un fallo que necesitó varias condiciones a la vez encaja con un árbol de fallos. Algo que funcionó hasta un cambio conocido encaja con el análisis de cambios. Si la pregunta es qué podría fallar y no qué falló, eso es un AMFE y no un análisis de causa raíz.
¿Qué diferencia hay entre los 5 porqués y un diagrama de Ishikawa?
Los 5 porqués siguen una cadena causal hacia atrás; un Ishikawa reparte causas candidatas por categorías. La diferencia que importa es estructural. Los 5 porqués solo pueden expresar una secuencia, así que no pueden sostener dos causas que tenían que estar presentes las dos, mientras que un Ishikawa sostiene decenas de candidatas pero no dice nada sobre cuál de ellas operó. Usados juntos, el Ishikawa es el paso divergente y los 5 porqués el convergente, ejecutado por una sola rama después de estrechar el campo.
¿Cuántos porqués bastan en un análisis de 5 porqués?
Cinco es una regla mnemotécnica, no una norma. La cadena para en la última causa que la organización puede cambiar y reconocería como causa: una especificación, un control, una carga de trabajo, una decisión de diseño. A veces bastan dos porqués y a veces nueve siguen quedándose cortos. Una cadena que pasa del punto de control y entra en la filosofía ha ido un porqué de más; una cadena que se abre en varias respuestas plausibles ha dejado de ser una cadena, lo que significa que el fallo es multifactorial y que la técnica se ha agotado.
¿El error humano es alguna vez una causa raíz?
Casi nunca, en el sentido de que actuar sobre él cambie algo. Una persona que ejecuta una tarea de forma distinta al procedimiento es a su vez un suceso con una causa: una instrucción que no coincide con el equipo, dos envases parecidos uno al lado del otro, una comprobación programada en la undécima hora de un turno. La prueba útil es si la siguiente persona competente de ese turno habría hecho lo mismo, y donde la respuesta es sí, el nombre que aparece en el informe es un sello de fecha sobre el fallo y no una explicación de él.