Los que fuimos criados en el mundo de los procesos, la industria y la automatización tenemos grabado casi en el inconsciente el Análisis de Causa Raíz (RCA). Fue el pan de cada día en los años 80 y 90, mientras en las radios sonaban The Cure, The Clash, Soda Stereo o Los Toreros Muertos, y las grandes potencias industriales del planeta —General Electric, Ford, Toyota, Siemens— dictaban cómo debía funcionar el trabajo, muchos queríamos aprender y hacer tal cual lo que ellos hacen (algo parecido a lo que ocurre hoy, que muchos quieren ser “el Uber, o el Booking de…” 😂)

Era la época en la que la industria de los átomos era la reina, no la de los bits y los bytes.

El Análisis de Causa Raíz como dogma

En ese contexto, el RCA era casi un dogma. Resolver problemas significaba, en la mayoría de los casos desarmar el mecanismo, encontrar la pieza defectuosa y reemplazarla. Todo funcionaba bajo la lógica del Reloj, la metáfora que Karl Popper usó para describir los sistemas complicados pero previsibles: engranajes claros, causalidad ordenada, soluciones definibles.

Para muchos como yo el análisis de causa raíz era el dogma y su más conocido artefacto era la Espina de pescado.

El diagrama de Ishikawa

Si el RCA fuera una caja de herramientas, el Ishikawa (diagrama de causa-raíz o Espina de pescado) sería su navaja suiza.
Pones el síntoma en la cabeza del pescado y luego acomodas causas potenciales en categorías fijas, casi siempre las “6M”: Mano de obra, Maquinaria, Materiales, Métodos, Medio ambiente, Medición

Simple, predecible, entendible y nos hacía quedar como expertos.

Era ideal para una época en la que creíamos que los problemas se podían diseccionar sin que cambiaran mientras los estudiabas. Ideal para creer entender por qué falló un lote de producción o por qué un proceso empezaba a generar errores repetidos.

Era la época donde, en muchos aspectos, reinaba el pensamiento determinista; los métodos probabilísticos, estocásticos y bayesianos existían, pero no eran la corriente principal fuera de ámbitos muy técnicos.

Cuando entendimos que el mundo era VUCA

Luego nos dimos cuenta de que el mundo era VUCA (Volátil, Incierto, Complejo y Ambiguo) y el Ishikawa se queda corto.

El Ishikawa funciona, esencialmente ,  porque asume tres cosas:

• Que las causas pueden separarse en cajas sin mezclarse.
• Que el sistema es estático, una especie de fotografía del problema.
• Que la causalidad es lineal: A produce B.
  

Todo eso es cierto… cuando el dominio que estamos analizando se comporta como un Reloj.

El problema es que no siempre lo hace (de hecho muchas veces no ha sido así,  los biólogos, antropólogos, epidemiólogos siempre lo han tenido claro), pero la industria muchas veces lo ignoraba (y aún lo ignora).

Cuando aplicamos esta lógica a situaciones como: Desarrollo de software, agilidad o agilismo, cambios culturales, baja innovación, pérdida de clientes, cambios culturales el Ishikawa se vuelve insuficiente.

Terminamos con una lista de causas que no muestran cómo se relacionan ni cuál es la que mueve el comportamiento. O intentando resolver muy estructuradamente un problema que no es el correcto.

Porque allí, volviendo a Popper, estamos ante un problema Nube (cloudlike), no Reloj (clocklike). Popper usó esta metáfora para distinguir fenómenos deterministas de fenómenos probabilísticos; hoy funciona muy bien como imagen para diferenciar problemas estables de problemas complejos.

Las palancas sistémicas

Aquí entran las palancas sistémicas.

Karl Popper llamaba a estos desafíos cloudlike: dinámicos, sin bordes definidos, sensibles al contexto.
Donella Meadows avanzó  y explicó que estos sistemas no se reparan: se pueden intentar intervenir desde las palancas de cambio. No siempre desde los síntomas, sino desde otros elementos: reglas, incentivos,  patrones de retroalimentación, narrativas internas, propósito compartido, paradigmas que moldean las decisiones.

Mientras el RCA actúa sobre lo visible, las palancas sistémicas actúan también sobre lo que sostiene lo visible.

Aplicándolo a un ejemplo: baja moral del equipo

La versión de análisis con causa raíz podría decir algo como:
“¿La moral está baja? La causa raíz es el salario.”
Subimos los salarios. El ambiente mejora unas semanas. Luego todo vuelve al punto de partida.

Esa intervención actúa sobre la pieza.
Pero el problema vive en el sistema.

Reitero: no creo que el análisis de causa raíz sea malo; creo que no aplica para problemas cloudlike como este.

Ahora veamos cómo se podría abordar con palancas de cambio, sin pretender certezas, con experimentos basados en hipótesis.

Tres posibles experimentos

1. ¿Qué está pasando en el sistema?

Observamos algunos posibles patrones como:

• La mayoría de las urgencias generan trabajo  extra.
• Las horas extra desgastan.
• El desgaste reduce la calidad.
• La baja calidad produce más urgencias.

Un círculo que se retroalimenta.

2. ¿Qué condiciones podrían estar generando ese comportamiento?

Observamos aspectos como:

• Se cree que la demanda llega “al azar” porque nunca se han estudiado sus comportamientos; solo se reacciona de manera reactiva.
• No se conversa ni se mide la demanda de servicio frente a la capacidad disponible.
• El equipo vive en modo “apaga incendios”.

Estas condiciones podrían influir en la moral del equipo.

3. ¿Qué experimentos podríamos probar aplicando palancas de cambio?

Experimento 1 — Ajustar reglas de trabajo

Hipótesis:  Si definimos criterios de aceptación antes de iniciar tareas, la ambigüedad bajaría y con ello el retrabajo.

Experimento:
Durante 3 semanas, ninguna historia entra a desarrollo sin criterios definidos.

Experimento 2 — Hacer visible la capacidad

Hipótesis:
Si el equipo y los stakeholders ven la capacidad disponible, podrían reducirse las urgencias asociadas a la sobrecarga.

Experimento:
Hacer visible la capacidad en un tablero compartido, revisarla semanalmente, analizar los límites del equipo y tomar decisiones para cuidar al equipo y el valor que entrega durante 4 semanas.

Experimento 3 — Cambiar la narrativa interna

Hipótesis:
Si necesitamos apagar fuegos, ajustamos prioridades de forma explícita y lo concertamos con el cliente.
Por ejemplo: dedicar un 30% del tiempo a atender urgencias (imaginemos que, según el histórico, esta dedicación suele ser suficiente) y renegociar la velocidad de entrega para adaptarse a ese 30%.
Si adoptamos una narrativa orientada a valor, algunos comportamientos y prioridades podrían ajustarse.

Experimento:
Conversación de equipo donde se redefine la narrativa:

“Podemos atender urgencias de una manera coherente y estructurada, siendo conscientes de las consecuencias de esa atención. Somos un equipo de valor.”

Esta narrativa se refuerza durante un mes en retrospectivas y otras ceremonias.

4. ¿Qué podría empezar a cambiar en el sistema?

Con el paso de varias semanas podrían aparecer señales como:

• Trabajo y ritmo más sostenible.
• Conversaciones menos tensas.
• Moral más estable.

No por una causa única, sino porque, eventualmente, cambiaron las condiciones que influyen en el comportamiento.

Y allí no para el análisis: se revisan los resultados, se adapta y se itera nuevamente hasta acercar el sistema al estado que deseamos (sí, como en un juego infinito, un ciclo PHVA o agilidad).

Por eso, para problemas Nube, herramientas como los Diagramas de Bucles Causales (Causal Loop Diagrams) pueden ayudar más: muestran refuerzos, compensaciones y ciclos que se repiten. Ayudan a detectar dónde una intervención pequeña puede transformar el sistema. Y no te dan una solución; te dan un posible experimento para aplicarlo, ver qué resultado te da y volver a iterar.

¿Te suena a agilidad?, ¿a innovación?
A mí también, por eso me estaba haciendo ruido este tema, hasta que lo entendí un poco mejor.

Clocklike vs. Cloudlike

• Cuando estamos ante un clocklike problem, el análisis de causa raíz es muy útil, incluso impecable.
• Cuando estamos ante un cloudlike problem, el análisis sistémico, incluyendo palancas de cambio, la experimentación y la iteración pueden servir más.

Gracias a Juan Daza por sembrar las semillas para esta reflexión.

En Castor trabajamos esta distinción con frecuencia,  estamos acostumbrados a navegar en los dos mundos. Es incómodo y nos equivocamos, pero obtenemos buenos resultados.

Tal vez las cosas en la transformación de tu empresa, la aplicación de la Agilidad, las experiencias de tus clientes o la manera como haces software no funcionan porque no ves a través de la Nube.

En Castor hemos aprendido a hacer que funcione un poco, mucho mejor. ¿Conversamos?

Si estás interesado en aprender un poco más te recomiendo estos artículos y videos:

• https://castor.com.co/clock-problems-y-cloud-problems
• https://castor.com.co/existe-la-complejidad-y-como-podriamos-abordarla
• https://castor.com.co/existe-la-complejidad-y-como-podriamos-abordarla

Y el libro : Pensar en Sistemas: Un Manual de Iniciación de Donella Meadows