Diagrama de flujo de análisis de causa raíz (árbol de decisión)
Diagrama de flujo de análisis de causa raíz dibujado como árbol de decisión: nueve preguntas encaminan el problema a los 5 porqués, un Ishikawa, un árbol de fallos, un escalado o un cierre documentado.
Cómo funciona
Renombra las calles con quienes deciden de verdad
Aquí las calles son autoridad de decisión, no departamentos: Responsable del proceso, Responsable de la investigación, Revisor de calidad y Dirección. Sustitúyelas por los roles que realmente responden a cada pregunta en tu organización, y mantén separado al responsable de la investigación del responsable del proceso siempre que puedas. Una investigación dirigida por quien responde del proceso tiende a asentarse en causas que resultan cómodas de enunciar.
Escribe la regla del enunciado del problema en la primera puerta
«¿El problema está bien definido?» solo funciona si alguien ha dicho qué significa definido. El criterio habitual es que el enunciado indique qué falló, dónde, cuándo y con qué frecuencia, y que no nombre ninguna causa. Un enunciado que ya contiene la causa —casi siempre alguna versión de error del operario— convierte el resto del árbol en un ejercicio de confirmación.
Fija el umbral de suficiencia en la puerta de datos
Decide qué exige «¿Datos suficientes para analizar?» antes de necesitarlo: una cronología que se pueda reconstruir, muestras retenidas o registros todavía dentro de su periodo de conservación, y al menos un testimonio de primera mano. Marca los elementos perecederos, porque son los que fijan la velocidad a la que hay que recopilar. Sin un umbral escrito, la rama Insuficientes no se toma nunca y el método se elige con lo que hubiera a mano.
Ajusta tus propias reglas de selección de método
El encaminamiento de este diagrama —Recurrente al Ishikawa, Técnico al árbol de fallos, Humano a los 5 porqués, Sistémico al Ishikawa— es un valor por defecto defendible, no una ley. Adáptalo a las técnicas en las que tu gente está realmente formada y añade las que uses, como el análisis de cambios o el análisis de barreras. Lo importante es que la regla exista y sea visible en el diagrama, para que la elección se pueda cuestionar en la revisión.
Define la regla de parada de los 5 porqués y la vía de salida
«¿Se llegó a una causa controlable?» es el nodo que impide que unos 5 porqués acaben en el clima o en la economía. Párate en la última causa que tu organización puede cambiar. Si la cadena se agota antes, o se abre en varias respuestas plausibles, el problema es multifactorial y la rama No lo lleva a un Ishikawa en lugar de dejar pasar una cadena endeble.
Acuerda el disparador de escalado y versiona ambos diagramas
Deja por escrito qué obliga a que «¿Causa bajo control local?» tome la rama Fuera del ámbito: causas que pertenecen a otro centro, a un proveedor o a una política que este equipo no puede cambiar; eventos notificables a un organismo regulador o a un cliente; cualquier cosa que afecte a la seguridad o a producto ya expedido. Después enlaza este árbol de decisión con el diagrama del proceso de análisis de causa raíz de extremo a extremo, y mantén ambos bajo control de versiones con sus aprobaciones registradas, para que investigadores y revisores trabajen sobre la misma versión autorizada.
Preguntas frecuentes
¿Un diagrama de análisis de causa raíz es un mapa de procesos o un árbol de decisión?
Puede ser cualquiera de los dos, y responden a preguntas distintas. Un mapa de procesos responde a qué pasa después y quién lo hace: abrir el problema, contenerlo, recopilar evidencia, analizar, verificar y entregar a CAPA. Un árbol de decisión —esta página— responde a qué técnica aplicar y quién decide, y sus ramas terminan en resultados distintos en lugar de converger en un único camino. La mayoría de las organizaciones necesitan los dos: el mapa de procesos para el procedimiento y el árbol de decisión para los juicios que hay dentro. Si lo que buscas es el flujo de extremo a extremo, usa la plantilla del proceso de análisis de causa raíz.
¿Cómo elijo entre los 5 porqués, un Ishikawa y un árbol de fallos?
Por la forma del problema, que es justo lo que comprueban las dos decisiones de método de este diagrama. Los 5 porqués encajan en una única cadena causal controlada por un solo equipo, donde cada respuesta se convierte en la siguiente pregunta. El Ishikawa, o diagrama de espina de pescado, encaja cuando podrían estar implicadas varias categorías —método, máquina, material, mano de obra, medición y medio ambiente— porque obliga al equipo a ir más allá de la primera rama plausible. El árbol de fallos encaja en un fallo técnico con un evento superior definible y componentes cuya lógica de fallo puedes recorrer hacia atrás. Un patrón recurrente casi siempre merece primero un Ishikawa, porque la recurrencia suele indicar condiciones y no una cadena aislada. Muchas investigaciones usan dos: generar candidatos en un Ishikawa y después aplicar los 5 porqués a la rama que sostiene la evidencia.
¿Qué pasa cuando los 5 porqués no llegan a una causa que controlemos?
Para eso está la decisión «¿Se llegó a una causa controlable?». Si la cadena se va más allá de lo que tu organización puede cambiar, o se bifurca en varias respuestas igual de plausibles, la rama No lleva el problema a un Ishikawa en lugar de aceptar el último eslabón como causa raíz. Este es el modo de fallo más habitual en la práctica: se sigue una cadena hasta llegar a algo indiscutible pero sobre lo que no se puede actuar, como la presión del mercado o la naturaleza humana, y aun así se escribe una acción contra ello.
¿Qué debe hacer el diagrama cuando la evidencia ya no existe?
Darle un resultado con nombre en lugar de dejarlo como un hueco. Este árbol tiene dos. Antes del análisis, «¿Datos suficientes para analizar?» puede enviar el caso a «Volver a la recopilación de evidencia», lo que detiene el avance en vez de continuar con datos endebles. Después del análisis, cuando la causa sigue siendo solo una hipótesis, «¿Se puede obtener más evidencia?» vuelve a la recopilación o termina en «Cerrar con limitación de datos». Cerrar declarando la limitación es un resultado legítimo y normalmente genera una acción propia: conseguir que la próxima vez ese dato exista.
¿Alguna norma exige un método concreto de análisis de causa raíz?
Las normas habituales de sistemas de gestión exigen determinar las causas de una no conformidad y actuar para que no vuelva a ocurrir, pero no prescriben cómo. El apartado 10.2 de la ISO 9001 está redactado así, y la ISO 13485 adopta el mismo enfoque para la acción correctiva y preventiva. Eso deja la elección del método en tus manos, que es precisamente por lo que merece la pena documentarla. Un árbol de decisión como este, con los criterios escritos en los nodos, le demuestra a un auditor que la técnica se eligió contra criterios declarados y no por preferencia, y la respuesta se mantiene igual sea quien sea quien dirija la investigación.