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.
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.
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.