Análisis de causa raíz (RCA): resolver para que no vuelva, no para hoy

# Análisis de causa raíz (RCA): resolver para que no vuelva, no para hoy

De ‘apagar fuegos’ a aprender: causas raíz que protegen margen y plazo.

La mayoría de empresas no tiene un problema de calidad. Tiene un problema de repetición.

El primer fallo duele. El segundo enfada. El tercero ya no es un fallo: es un sistema.

Cuando yo entro en una operación donde “siempre pasa algo”, casi siempre encuentro lo mismo: se trabaja muchísimo para resolver lo urgente, pero se trabaja muy poco para evitar lo recurrente.

Y lo recurrente, en negocios de proyecto, tiene una consecuencia clara: se come margen y se come plazo, pero lo hace en cuotas pequeñas, difíciles de imputar, fáciles de normalizar.

Este artículo no es un tutorial de herramientas. No vas a ver plantillas, ni pasos cerrados, ni “aplica esta técnica y listo”. Lo que sí vas a ver es lo que de verdad importa: cómo distinguir un RCA que aprende de uno que solo documenta, y qué señales te dicen si tu organización está resolviendo para “que no vuelva” o simplemente para “llegar a hoy”.

## El error de base: confundir “resolver” con “aprender”

Resolver es apagar el incendio.

Aprender es rediseñar el bosque para que no arda igual.

En operaciones, resolver suele significar:

• • sustituir una pieza
• • ajustar una bisagra
• • retocar un lacado
• • volver a enviar un equipo
• • pedir “más cuidado”.

Eso calma al cliente y salva la entrega. Bien.

Pero aprender significa otra cosa:

• • entender por qué ese defecto se volvió posible
• • por qué se repite
• • por qué el sistema no lo detectó antes
• • y qué decisión (o falta de decisión) lo está alimentando.

Si una organización confunde ambas cosas, se convierte en experta en urgencias. Y eso, al principio, incluso genera orgullo. Hasta que el orgullo se vuelve deuda.

## La señal más clara de que necesitas RCA de verdad

Cuando el equipo usa frases como:

• • “esto ya lo vimos”
• • “otra vez lo mismo”
• • “depende de quién lo haga”
• • “en taller queda bien, en casa cambia”
• • “no sabemos por qué, pero pasa”

Esa última frase es especialmente peligrosa. Porque no describe ignorancia; describe normalización.

Cuando un defecto se normaliza, deja de ser “incidencia” y pasa a ser parte del proceso, pero sin control ni coste reconocido.

## Por qué el RCA protege margen aunque no “produzca” nada

Hay un tipo de pérdida que casi nadie ve porque no se factura como pérdida:

• • llamadas
• • correos
• • coordinación
• • replanificación
• • segundas visitas
• • piezas urgentes
• • tensión entre áreas
• • tiempo mental.

Eso es COPQ, aunque nadie lo registre como tal.

El RCA no “fabrica” piezas, pero reduce ese ruido. Y el ruido es margen, solo que con otra máscara.

## El RCA que falla: el que se hace para cerrar un expediente

Yo he visto RCA impecables… que no cambian nada.

Documentos con diagramas perfectos, reuniones largas, conclusiones correctas… y al mes, el mismo defecto con otro nombre.

Cuando eso pasa, casi siempre hay una causa escondida: el RCA se hizo para demostrar diligencia, no para cambiar el sistema.

Y si el objetivo es demostrar, el resultado es papel.

## El punto ciego más común: perseguir el síntoma más visible

En instalación, por ejemplo, se ve el defecto final: el canto, el ajuste, el remate.

Entonces el “por qué” se convierte en:

• • “el instalador no ajustó bien”
• • “la pieza venía tocada”
• • “hubo prisa”
• • “faltaba información”

Puede ser cierto. Pero si te quedas ahí, estás culpando a la última mano.

Yo prefiero una pregunta más incómoda:

¿qué condición del sistema hizo probable que la última mano tuviera que improvisar?

Ahí suele aparecer la verdad: tolerancias, interfaces, variabilidad, datos incompletos, cambios sin gobierno, embalaje, secuencia de montaje, coordinación de obra.

## La diferencia entre causa raíz y causa “razonable”

Una causa razonable suena bien y termina la conversación.

Una causa raíz cambia decisiones.

Ejemplos de causas razonables:

• • “falta formación”
• • “falta atención”
• • “falta comunicación”
• • “hubo prisa”

No digo que sean falsas. Digo que son baratas: explican todo y no explican nada.

Una causa raíz, en cambio, suele tener esta forma:

• • una interfaz mal definida
• • una regla difusa
• • un dato que no es verdad única
• • un punto de control que llega tarde
• • un incentivo que premia velocidad sobre precisión
• • una variabilidad que se acepta como normal.

La causa raíz no siempre es técnica. Muchas veces es de diseño organizativo.

## El trade-off que nadie quiere aceptar: aprender requiere parar “un poco”

El RCA real exige algo que incomoda: una micro-pausa.

No hablo de parar la fábrica. Hablo de parar el piloto automático.

Si cada incidencia se resuelve con urgencia total, no hay espacio para:

• • mirar el patrón
• • comparar casos
• • separar coincidencia de causalidad
• • decidir qué se estandariza.

Por eso el RCA falla en culturas heroicas: si el héroe es el que corre, el aprendizaje es el que estorba.

Y cuando la cultura premia correr, el sistema castiga pensar.

## Señales de madurez: cuándo el RCA está funcionando

Yo reconozco un buen sistema de RCA por señales, no por documentos:

• • el mismo defecto no vuelve con otro nombre
• • el equipo habla en términos de condiciones del sistema, no de culpables
• • las acciones posteriores se integran en estándares vivos
• • la dirección protege el tiempo mínimo para aprender
• • operaciones y postventa comparten lenguaje (no solo tickets)
• • se decide qué NO se investiga (porque no todo merece el mismo foco).

Ese último punto es clave: madurez no es investigar todo. Es elegir bien.

## El error más caro: investigar “lo espectacular” e ignorar “lo frecuente”

Hay incidencias grandes que impresionan.

Y hay incidencias pequeñas que matan.

El RCA suele irse a lo espectacular porque duele más en reputación inmediata. Pero el margen se suele escapar por lo frecuente: pequeños defectos, pequeñas reprogramaciones, pequeñas urgencias.

Yo suelo preguntar:

• • ¿qué te hace perder más energía en un mes?
• • ¿qué te roba más agenda sin que nadie lo vea?
• • ¿qué defecto te obliga a “explicar” más que a “entregar”?

Ahí suele estar el foco real.

## Preguntas de diagnóstico que uso para detectar si hay aprendizaje real

Sin buscar culpables, yo busco arquitectura:

• • ¿Qué parte del defecto se podía detectar antes y no se detectó? ¿Por qué?
• • ¿Qué “supuesto” del proceso se rompió sin que nadie lo supiera?
• • ¿Dónde se crea la variabilidad: diseño, datos, fabricación, logística, obra?
• • ¿Qué decisión se toma tarde, siempre tarde?
• • ¿Qué regla existe “en la cabeza” pero no en el sistema?
• • ¿Qué cambio se acepta sin evaluar impacto (porque “es pequeño”)?
• • Si el mismo caso lo ejecuta otro equipo, ¿el resultado cambia? ¿Por qué?

Cuando esas preguntas no tienen respuesta, el sistema vive de memoria y suerte.

## El problema de fondo: las causas raíz suelen cruzar fronteras

El defecto final se ve en un sitio, pero la causa vive en otro.

• • El instalador “sufre” una pieza que salió de taller con tolerancias frágiles.
• • Taller “sufre” un dato de producto ambiguo que viene de diseño/ventas.
• • Compras “sufre” una sustitución que cambia comportamiento de montaje.
• • Postventa “sufre” una decisión comercial que prometió algo sin margen operativo.

Si el RCA se hace dentro de un silo, casi siempre termina en “falta de coordinación”.

Y esa es la forma elegante de decir: nadie tiene propiedad del sistema completo.

## Cómo se ve un RCA útil sin volverse burocracia

Un RCA útil tiene dos efectos visibles:

• 1. reduce recurrencia

2. aumenta claridad.

Lo burocrático, en cambio, aumenta papeles y mantiene recurrencia.

Yo considero que hay burocracia cuando:

• • hay más reuniones que cambios
• • hay más “seguimiento” que aprendizaje
• • hay más lenguaje que evidencia
• • hay más “responsables” que propiedad real.

Y hay aprendizaje cuando el estándar cambia y se sostiene.

## El lugar donde el RCA se convierte en margen

El margen aparece cuando el RCA llega a decisiones como:

• • qué interfaz no se toca (porque sostiene compatibilidad)
• • qué variabilidad se permite y cuál no
• • qué punto de control se adelanta (para detectar antes)
• • qué información deja de ser opinable
• • qué criterio se vuelve “regla” y deja de ser debate.

No necesito números para saber si eso está pasando. Lo veo en el clima: menos urgencias, menos sorpresas, más previsibilidad.

## Lo que yo NO recomiendo (porque crea teatro)

• • RCA para cada incidencia, sin priorización.
• • RCA como búsqueda de culpable (mata la verdad).
• • RCA con acciones genéricas (“formación”, “comunicar”, “revisar”).
• • RCA sin dueño claro del cambio posterior.
• • RCA sin conexión con estándares (si no cambia el sistema, vuelve).
• • RCA que depende de una persona “buena” (si se va, desaparece).

El teatro de calidad se parece mucho a la calidad… hasta que miras la recurrencia.

## Checklist rápido: señales de “apaga fuegos” vs “aprendizaje”

Marca mentalmente:

Apaga fuegos

• • se celebra la velocidad de cierre del ticket
• • se repite el mismo defecto
• • las acciones son genéricas
• • el aprendizaje no cambia estándares
• • el sistema depende de héroes.

Aprendizaje

• • se celebra la reducción de recurrencia
• • se acota variabilidad
• • las acciones cambian decisiones
• • el estándar vive y se respeta
• • el sistema funciona sin heroísmo.

Si tu organización vive más en la primera columna, tu problema no es calidad: es sistema.

## Cierre

El RCA no es una técnica. Es una postura: resolver para que no vuelva, no solo para hoy.

Cuando esa postura existe, protege margen, protege plazo y, sobre todo, protege la calma operativa que un negocio premium necesita para cumplir su promesa.

Si quieres, puedo ayudarte a diagnosticar dónde se te está colando la recurrencia, qué patrones están drenando COPQ sin que nadie los sume, y qué decisiones de sistema te faltan para pasar de apagar fuegos a aprender.

Diagnóstico express