GESTIÓN DE CALIDAD & CONFIABILIDAD

Del error humano a la falla del sistema: cómo funciona realmente el Análisis de Causa Raíz

Por qué preguntar “¿quién falló?” rara vez evita que un evento adverso vuelva a ocurrir, y qué preguntar en su lugar.

Un paciente recibe la dosis equivocada. Una turbina se detiene sin previo aviso a mitad de una campaña de producción. Un vuelo aborta el aterrizaje a último segundo. Son eventos de mundos distintos, pero comparten una tentación casi irresistible: cerrar el caso apuntando a la persona que estaba más cerca del error cuando ocurrió. El Análisis de Causa Raíz (Root Cause Analysis, RCA) existe precisamente para resistir esa tentación y para responder una pregunta más incómoda y más útil: ¿qué tuvo que estar mal en el sistema para que esa persona, en ese momento, tomara esa decisión?

Esta pregunta no es un matiz semántico. Es la diferencia entre una organización que repite sus propios errores con nombres distintos y una que aprende de ellos. El sector salud lo ha aprendido —muchas veces de la forma más dura— en las últimas dos décadas y media, y ha convertido al RCA en una de sus herramientas de gestión de calidad más exigidas por reguladores y acreditadores. Pero el método no nació en un hospital: nació en la industria pesada, en la aviación y en la energía nuclear, y hoy sigue viajando en ambas direcciones entre esos mundos. Este artículo recorre qué es el RCA, de dónde viene, cómo se ejecuta paso a paso, qué herramientas lo sostienen y por qué un ingeniero de confiabilidad de planta y un comité de calidad hospitalario terminan, sin saberlo, hablando el mismo idioma.

Cuando algo sale mal, la explicación más disponible suele ser la más superficial: alguien se distrajo, alguien no siguió el protocolo, alguien cometió un error de cálculo. Esa explicación no es falsa —probablemente sea cierta—, pero es incompleta. Es lo que en la literatura de calidad se llama una causa aparente: el eslabón visible de una cadena que, si se sigue hacia atrás, casi siempre lleva a decisiones de diseño, de dotación de personal, de presión operativa o de cultura organizacional tomadas mucho antes y mucho más arriba en la jerarquía.

Resulta útil pensar en cualquier evento adverso como un iceberg. Lo que se reporta —el error de medicación, la parada no programada, el defecto de producto— es apenas la porción visible sobre la línea de flotación. Debajo hay capas sucesivas de causas cada vez más estructurales, y la causa raíz casi siempre vive en la capa más profunda: no es un acto aislado, es una condición del sistema que hace que ese tipo de error sea posible, e incluso probable, tarde o temprano.

Fig. 1 — El evento reportado es solo la punta visible. La causa raíz vive en las condiciones estructurales que hicieron posible el error, no en el acto individual que lo desencadenó.

De ahí que la definición operativa de RCA no sea “encontrar al culpable” sino identificar la condición o condiciones sin las cuales el evento no habría ocurrido, y que —de corregirse— evitarían con razonable confianza que vuelva a ocurrir en el futuro. Esa definición tiene dos consecuencias prácticas importantes. Primero, obliga a distinguir entre corregir el síntoma (reentrenar a la persona, sancionarla, recordarle el protocolo) y corregir la causa (rediseñar el proceso para que el error deje de ser posible). Segundo, reconoce que casi ningún evento serio tiene una sola causa: lo habitual es una combinación de fallas latentes —decisiones organizacionales tomadas tiempo atrás— con fallas activas —el error concreto del momento— y con barreras que deberían haber detenido la cadena y no lo hicieron.

Un poco de historia

El RCA no es un invento del sector salud. Sus raíces están en la ingeniería industrial de mediados del siglo XX —el análisis sistemático de fallas en manufactura, la investigación de accidentes en la industria nuclear y petroquímica, y los sistemas de reporte de incidentes de la aviación comercial—, todos ellos entornos donde un evento adverso puede ser catastrófico y donde la industria aprendió, muchas veces tras tragedias, que investigar solo al operador deja intacta la trampa que atrapará al siguiente. La adopción formal en hospitales se aceleró de forma notable a partir de 1999, cuando el Institute of Medicine estadounidense publicó su influyente informe sobre errores médicos evitables, y organismos acreditadores como The Joint Commission comenzaron a exigir un RCA formal después de eventos centinela. Desde entonces, el método se ha extendido a sistemas de salud de todo el mundo, adaptando un lenguaje —causa raíz, barrera, factor contribuyente— que originalmente hablaba de plantas y aeronaves, no de pacientes.

Un malentendido frecuente reduce el RCA a una sola técnica —generalmente los “cinco porqués”— aplicada de forma aislada e improvisada tras el evento. En la práctica, un RCA riguroso es un proceso de varias etapas, cada una con su propio objetivo, su propio tipo de pensamiento (analítico en unas, creativo en otras) y su propia duración esperada. Sin esta estructura, es fácil detenerse en la primera explicación plausible —lo que en inglés se conoce como root cause-itis: declarar “encontrada” la causa raíz demasiado pronto porque encaja con lo que el equipo ya sospechaba.

Fig. 2 — El proceso completo alterna fases de pensamiento analítico —acotar, verificar, medir— con fases de pensamiento creativo o divergente —generar causas posibles, idear soluciones.

Paso 1 — Definir el evento

Antes de buscar causas hay que acotar con precisión qué ocurrió, cuándo, dónde, con qué consecuencia y bajo qué condiciones. Esto incluye activar formalmente el proceso, convocar y mandatar un equipo multidisciplinario —nunca una sola persona, y nunca solo quienes estuvieron directamente involucrados—, planificar el alcance y el cronograma del análisis, y describir el evento con el mayor detalle factual posible, evitando desde el inicio cualquier lenguaje que atribuya intención o culpa. Un error común en esta etapa es confundir “definir el evento” con “definir el problema que creemos que existe”: lo primero describe hechos verificables; lo segundo ya es una hipótesis disfrazada de descripción.

Paso 2 — Encontrar las causas

Con el evento acotado, el equipo genera de forma amplia y sin autocensura la lista de factores que pudieron contribuir, apoyándose en técnicas divergentes como la lluvia de ideas estructurada y el diagrama de causa-efecto (más adelante se detalla). El objetivo aquí no es aún encontrar “la” causa, sino mapear el universo de causas posibles a lo largo de las categorías típicas: personas, procesos, equipos y tecnología, políticas y procedimientos, entorno físico, y comunicación.

Paso 3 — Hallar la causa raíz

De la lista amplia de causas posibles, el equipo profundiza en las más plausibles usando técnicas convergentes —los cinco porqués son la más conocida— hasta llegar a una condición que, de no existir, habría roto la cadena causal. Esta es la fase más difícil de disciplinar: exige mantener la calma ante explicaciones incómodas, resistir la presión de cerrar rápido, y distinguir con honestidad entre una causa raíz real y un factor contribuyente que simplemente estaba presente.

Paso 4 — Diseñar soluciones

Identificada la causa raíz, el equipo vuelve a un modo creativo para generar posibles soluciones, involucrando explícitamente a quienes ejecutarán el cambio en el día a día —una de las variables que más predice si una acción correctiva sobrevivirá seis meses después del análisis—.

Paso 5 — Actuar

Las soluciones se convierten en un plan de acción con responsables, plazos y recursos, y se implementan. Aquí es donde el análisis técnico se topa con la realidad organizacional: financiamiento, resistencia al cambio, prioridades en competencia. Herramientas como el análisis de campo de fuerzas ayudan a anticipar qué fuerzas empujarán la implementación y cuáles la frenarán.

Paso 6 — Medir y evaluar

La última etapa, con frecuencia la más descuidada, verifica si la acción realmente funcionó: ¿bajó la tasa de recurrencia?, ¿la barrera instalada resiste condiciones reales de trabajo?, ¿aparecieron efectos secundarios no previstos? Un RCA sin esta etapa de cierre es, estrictamente, un análisis inconcluso: se documentó una hipótesis de solución, pero nunca se confirmó.

Dos herramientas concentran la mayor parte del trabajo de campo de un RCA. La primera, el diagrama de causa-efecto —también llamado diagrama de Ishikawa o de espina de pescado— organiza visualmente las causas posibles de un evento en categorías, evitando que el equipo se quede fijado en una sola línea de explicación. La segunda, los cinco porqués, profundiza verticalmente en una causa concreta hasta romper la cadena en su eslabón más estructural.

Fig. 3 — Un diagrama de espina de pescado adaptado a un evento de medicación. Las mismas seis categorías funcionan igual de bien para una falla de bomba centrífuga en planta.

El valor del diagrama no está en llenarlo con exhaustividad decorativa, sino en obligar al equipo a mirar categorías que de otro modo ignoraría. Es habitual que, dejado a su propio impulso, un equipo se concentre en “personas” y “equipos” —lo tangible, lo fácil de señalar— y evite “políticas” y “cultura” —lo incómodo, lo que compromete a la gerencia—. Un facilitador experimentado usa el diagrama precisamente para forzar esa mirada incómoda.

Los cinco porqués, en la práctica

Una vez identificada una causa candidata dentro de alguna de esas categorías, se le pregunta “¿por qué ocurre esto?” de forma repetida, generalmente entre tres y siete veces, hasta llegar a una condición estructural sobre la que la organización puede actuar directamente. El nombre sugiere una cifra fija, pero la disciplina real está en el criterio de parada: se detiene cuando la siguiente pregunta ya no revela una causa nueva sino que empieza a repetir la anterior con otras palabras, o cuando se llega a una condición que escapa al control razonable del equipo.

Fig. 4 — Cada “por qué” desplaza la explicación de un acto individual hacia una condición del sistema. La causa raíz final es algo que un procedimiento puede corregir; ningún “por qué” anterior lo era por sí solo.

Dos advertencias son importantes. La primera: los cinco porqués funcionan bien para cadenas causales relativamente lineales, pero se quedan cortos ante eventos con múltiples causas concurrentes; en esos casos conviene combinarlos con el diagrama de causa-efecto o con árboles de causas que se ramifican. La segunda: la técnica es tan buena como la honestidad del equipo que la aplica. Es fácil —y tentador— dirigir cada “por qué” hacia una conclusión que ya se tenía en mente. Un buen facilitador vigila activamente ese sesgo de confirmación.

Encontrar la causa raíz es solo la mitad del trabajo; la otra mitad es elegir una acción correctiva que realmente cierre esa causa y no dependa, otra vez, de que un humano recuerde hacer algo bien bajo presión. La jerarquía de controles —otro concepto que el sector salud tomó prestado de la seguridad industrial— ordena las acciones posibles de más a menos efectivas, precisamente en función de cuánto dependen de la vigilancia y la memoria humanas.

Fig. 5 — Cuanto más abajo en la pirámide, más depende la acción de que una persona recuerde y ejecute algo correctamente cada vez. Cuanto más arriba, más elimina la posibilidad misma del error.

Aplicado al ejemplo anterior: “recordar al personal la importancia de no interrumpir durante cálculos” es un control débil, en la base de la pirámide. “Instalar una bomba de infusión con límites de dosis programados que bloquean valores fuera de rango” es un control de ingeniería, mucho más arriba. “Rediseñar el flujo para que ningún cálculo de dosis de alto riesgo se realice sin verificación cruzada obligatoria, registrada en el sistema” combina un control administrativo fuerte con una barrera casi imposible de saltar por accidente. La misma lógica es exactamente la que aplica un ingeniero de confiabilidad quien, tras la falla repetida de un sello mecánico, decide no limitarse a “reforzar la inspección” sino rediseñar el sistema de sellado para que la condición que rompía el sello deje de presentarse.

Comparación de tipos de barrera según su dependencia de la memoria humana

La literatura y la experiencia de campo coinciden en tres niveles distintos donde un proceso de RCA puede fracasar, incluso cuando el equipo sigue los pasos correctos en apariencia.

A nivel del sistema

Cuando la organización no destina tiempo protegido para el análisis, no tiene una base de datos donde consolidar eventos y acciones, o no da seguimiento a si las acciones correctivas realmente se implementaron, el RCA se convierte en un ejercicio de cumplimiento documental sin efecto real. Un síntoma clásico: el mismo tipo de evento se repite cada pocos meses, cada vez con un informe de RCA distinto que “descubre” una causa raíz ligeramente distinta.

A nivel de las personas

El miedo a las consecuencias disciplinarias es el enemigo más antiguo del RCA. Si quienes participan en el evento temen que hablar con franqueza les cueste el puesto, la información que llega al equipo de análisis estará filtrada, incompleta o directamente falsa. Las organizaciones que obtienen RCA de mejor calidad son, casi sin excepción, las que han logrado separar con claridad la investigación de las causas de la eventual gestión disciplinaria de una falta individual genuina —que puede existir, pero es la excepción, no la explicación por defecto—.

A nivel de la práctica

Incluso con buena voluntad organizacional, un equipo puede ejecutar el método de forma superficial: detenerse en la primera causa “razonable”, no involucrar a quienes trabajan realmente en el proceso analizado, o generar acciones correctivas genéricas que nadie es responsable de implementar en un plazo concreto. La calidad de un RCA depende tanto de la disciplina metodológica como de la habilidad de facilitación de quien conduce las sesiones.

Quien ha liderado paradas de planta, gestión de activos o confiabilidad operacional reconocerá cada elemento descrito hasta aquí, con otro vocabulario. El análisis de fallas en equipos rotativos, la investigación de un paro no programado, la revisión de un incidente de seguridad de proceso: todos usan la misma arquitectura de pensamiento —separar la causa aparente de la causa raíz, distinguir causas próximas de condiciones sistémicas, clasificar barreras por su fortaleza real y no por su costo de implementación—. La diferencia no está en el método sino en el vocabulario y en el tipo de evidencia disponible: un hospital investiga con entrevistas, historias clínicas y registros de turno; una planta investiga con datos de sensores, curvas de vibración y bitácoras de mantenimiento. La estructura lógica del análisis —los seis pasos, el diagrama de causa-efecto, los cinco porqués, la jerarquía de controles— es prácticamente intercambiable entre ambos mundos.

Esto tiene una implicación práctica directa para cualquier organización industrial que esté fortaleciendo su cultura de confiabilidad: no hace falta inventar un método propio desde cero. Adaptar el marco de RCA que la industria de la salud ha refinado durante más de veinte años bajo presión regulatoria —con sus plantillas de causa-efecto, sus criterios de parada para los cinco porqués, sus jerarquías de barreras— es, con ajustes menores de vocabulario, aplicable de forma directa al análisis de una parada de planta, una falla de equipo crítico o una desviación en un proceso de manufactura.

Un RCA bien ejecutado una sola vez demuestra que el método funciona. Una organización que lo sostiene en el tiempo —hasta convertirlo en la respuesta automática ante cualquier evento significativo— es harina de otro costal, y requiere infraestructura además de voluntad:

• Un umbral claro de activación: criterios objetivos que definen qué tipo de evento dispara un RCA formal, para no depender del criterio ad hoc de quien esté de turno ese día.

• Facilitadores entrenados, no solo expertos técnicos en el tema investigado: alguien capaz de conducir la conversación sin que se convierta en una sesión de señalamientos.

• Una base de datos centralizada de eventos, causas raíz y acciones, que permita detectar patrones que ningún RCA individual vería por sí solo —la misma causa raíz apareciendo en distintas unidades, por ejemplo—.

• Seguimiento explícito de acciones con dueño y fecha, y una segunda revisión que confirme que la acción implementada tuvo el efecto esperado y no generó consecuencias no previstas.

• Protección relativa —“just culture”— que separe el análisis de causa raíz de la gestión disciplinaria individual, reservando esta última para negligencia genuina o violación intencional, no para el error humano ordinario que cualquier sistema bien diseñado debería tolerar sin consecuencias catastróficas.

Ninguno de estos cinco elementos es una técnica de análisis; son condiciones organizacionales. Y ahí está, quizás, la lección más importante que deja el RCA bien entendido: el método puede ser impecable en el papel, pero solo produce mejora real cuando la organización que lo aplica está dispuesta a escuchar respuestas que comprometen decisiones tomadas por encima de la persona que estaba presente cuando el evento ocurrió.

Ingeniería y Gestión del Conocimiento — contenido técnico sobre confiabilidad, gestión de activos y metodologías de mejora continua para profesionales de habla hispana.