Cómo encontrar la causa raíz de un problema

Para encontrar la causa raíz de un problema, hay que describirlo con precisión, ir a ver dónde ocurre, mapear las causas posibles con amplitud mediante un diagrama de Ishikawa, acotarlas con datos y seguir a las candidatas más sólidas con los «cinco porqués» hasta llegar a algo que se pueda cambiar. Por último, hay que probar la causa: si corregirla no reduce el problema, no se ha encontrado. La mayoría de los equipos se saltan el primer y el último paso, y por eso sus «causas raíz» acaban siendo opiniones.

Por qué los equipos se quedan en la primera causa

La primera explicación que suena bien suele ganar, sobre todo cuando la aporta alguien con rango. «El personal necesita más formación» y «el sistema es lento» son las dos falsas causas raíz más comunes en cualquier organización. Resultan cómodas porque son parcialmente ciertas y señalan a otro.

Una causa raíz supera tres pruebas. Está al alcance: la organización puede cambiarla. Explica el patrón: cuándo y dónde aparece el problema, y dónde no. Y eliminarla reduce el problema. Una causa que no supera alguna de estas pruebas es un síntoma, un factor contribuyente o una conjetura.

Además, rara vez hay una sola causa raíz. La mayoría de los problemas persistentes en servicios y operaciones vienen de dos o tres causas que actúan juntas. Conviene contar con encontrar varias y ordenarlas.

Cómo encontrar la causa raíz: siete pasos

1. Escribir el problema como un hecho, no como un juicio

«La atención al cliente es mala» no se puede analizar. «En septiembre, el 31 % de las solicitudes de reembolso tardó más de diez días hábiles, frente a un objetivo de cinco» sí. Hay que escribir qué está pasando, dónde, desde cuándo y en qué medida, y cómo es la normalidad. Si no se pueden rellenar las cifras, esa es la primera tarea.

También hay que escribir lo que el problema no es. Si los reembolsos tardíos se dan en una región pero no en otra, o en pagos con tarjeta pero no en transferencias bancarias, ese contraste es una de las mejores pistas.

2. Ir a ver

Antes de cualquier taller, hay que pasar tiempo donde ocurre el problema. Sentarse con el equipo que tramita los reembolsos, seguir un caso de principio a fin, ver a un cliente intentar completar la gestión. La observación contextual capta los apaños, la información que falta y los traspasos que ningún informe muestra. Sin este paso, el análisis en una sala de reuniones suele reproducir lo que la gente ya creía.

3. Mapear el proceso

Hay que dibujar los pasos como ocurren en realidad, no como dice el procedimiento. Un diagrama de flujo del proceso muestra enseguida los bucles, los puntos de espera y los traspasos entre equipos. Los problemas tienden a acumularse en los traspasos, donde cada parte da por hecho que la otra está revisando.

4. Mapear las causas posibles con amplitud mediante un diagrama de Ishikawa

El diagrama de espina de pescado, o de causa y efecto, lo popularizó Kaoru Ishikawa en la gestión de la calidad japonesa en la década de 1960, y por eso mucha gente lo sigue llamando diagrama de Ishikawa. Se escribe el problema en la cabeza y se dibujan ramas principales para las categorías de causa. El conjunto clásico es personas, métodos, máquinas, materiales y medición; en servicios, muchos equipos usan personas, procesos, normativa, tecnología, información y entorno.

Se pide al grupo que rellene todas las ramas antes de discutir ninguna. El objetivo de este paso es la amplitud. Se están enumerando candidatas, no dictando veredictos. Hay que marcar las que el grupo puede respaldar con algo que ha visto y las que son solo sospechas.

5. Acotar con datos

Ahora toca contrastar las candidatas con los hechos. Se toma una muestra de casos y se etiqueta cada uno con su causa probable. Un análisis de Pareto, llamado así por el economista Vilfredo Pareto y llevado al trabajo de calidad por Joseph Juran, ordena las causas por frecuencia y suele mostrar que unas pocas explican la mayoría de los casos. Juran las llamó «los pocos vitales». Cincuenta casos bien etiquetados suelen bastar para ver el patrón.

Si no se pueden conseguir datos, se hace una comprobación breve: dos semanas de marcas de recuento hechas por quienes realizan el trabajo es mejor que nada.

6. Preguntar «por qué» hasta llegar a algo que se pueda cambiar

Se toma cada una de las dos o tres causas más sólidas y se pregunta por qué ocurre, luego por qué ocurre eso, y así sucesivamente. La técnica se atribuye a Sakichi Toyoda y la hizo famosa Taiichi Ohno como parte del Sistema de Producción de Toyota. Cinco es una regla orientativa, no un objetivo; pueden hacer falta tres o siete.

Tres disciplinas mantienen honestos los cinco porqués. Responder a cada «por qué» con un hecho, no con una sensación. Permitir que la cadena se ramifique cuando hay dos respuestas reales. Y detenerse al llegar a algo que la organización controla y podría cambiar; ir más allá suele acabar en «porque las personas somos humanas» o «por el presupuesto», que no ayudan a nadie.

Incluso dentro de Toyota, los cinco porqués tienen críticos que los consideran demasiado básicos para problemas complejos. Por eso aquí van después del Ishikawa y de los datos, no en su lugar.

7. Probar la causa antes de corregirla

Hay que formular la causa raíz como una afirmación que se pueda refutar: «Los reembolsos se retrasan sobre todo porque los casos a los que les falta la referencia bancaria se dejan en espera sin que nadie contacte con el cliente». Después se diseña una prueba pequeña. Se corrige para un equipo, una región o durante dos semanas, y se observa si el problema se mueve. Si no lo hace, se vuelve al paso 5 con lo aprendido.

Elegir la herramienta adecuada para el problema

• Los cinco porqués para un fallo único y bien definido, con una cadena de hechos clara.
• El diagrama de Ishikawa cuando pueden intervenir muchos factores y se necesita la visión de todo el equipo.
• El análisis de Pareto cuando hay muchos casos y hay que saber qué causas pesan más.
• El árbol de problemas cuando el problema es amplio, de carácter social u organizativo, y hay que ver causas y efectos por capas.
• El análisis modal de fallos y efectos cuando se quiere prevenir problemas en un proceso nuevo antes de que ocurran.

Ejemplo ilustrativo

Ilustrativo. Una empresa de servicios públicos de tamaño medio en Canadá recibía quejas porque los reembolsos de facturas pagadas de más eran lentos. La primera explicación, planteada en una reunión de dirección, fue que el equipo de reembolsos no tenía suficiente personal.

La responsable de mejora escribió el problema como un hecho: el 31 % de los reembolsos del último trimestre tardó más de diez días hábiles, sobre todo en una de tres regiones. Pasó dos mañanas con el equipo de reembolsos y siguió seis casos de principio a fin. Una sesión con el diagrama de Ishikawa produjo 27 causas posibles repartidas en seis ramas.

Después etiquetó 60 casos tardíos. Pareto mostró que 38 tenían algo en común: los datos bancarios del cliente estaban incompletos, así que el caso quedaba en espera. Los cinco porqués sobre esa causa fueron así: en espera porque faltaba la referencia bancaria; faltaba porque el formulario online no la exigía; no la exigía porque el campo pasó a ser opcional cuando el formulario se migró a un nuevo sistema; nadie se dio cuenta porque los casos en espera no aparecían en el informe diario del equipo.

La prueba fue barata: hacer obligatorio el campo en la región con más casos tardíos y añadir los casos en espera al informe diario. En un mes, los reembolsos tardíos en esa región cayeron de forma notable, y la cuestión de la plantilla no volvió a salir.

Errores comunes

• Empezar con el Ishikawa en una sala de reuniones. Sin hechos ni observación, recoge opiniones con un diagrama alrededor.
• Dejar que la teoría de una persona marque el marco. Primero hay que recoger las causas en silencio y por escrito; después, debatir.
• Quedarse en el «error humano». Las personas cometen errores en sistemas que los permiten. Hay que preguntar qué hizo fácil el error.
• Ir más allá del propio alcance. «Por la normativa» puede ser cierto, pero si no se puede cambiar, hay que detenerse un nivel antes, en lo que sí se puede.
• Una sola cadena. Si los cinco porqués nunca se ramificaron, probablemente se pasó por alto una causa contribuyente.
• Cantar victoria sin una prueba. Una causa raíz es una hipótesis hasta que eliminarla reduce el problema.
• Convertir el análisis en búsqueda de culpables. Si la gente espera culpas, oculta los hechos que se necesitan. Hay que decir claramente desde el principio que se está mirando el sistema.

Preguntas frecuentes

¿Cuáles son los pasos del análisis de causa raíz? Definir el problema con hechos, observar dónde ocurre, mapear el proceso, enumerar con amplitud las causas posibles, acotarlas con datos, seguir las más sólidas con el «por qué» y probar la causa con un cambio pequeño antes de desplegar una solución.

¿Qué diferencia hay entre los cinco porqués y un diagrama de Ishikawa? El diagrama de Ishikawa se abre a lo ancho: enumera muchas causas posibles por categorías. Los cinco porqués van en profundidad: siguen una causa hasta su origen. El Ishikawa sirve para encontrar candidatas y los cinco porqués, para rastrear las más sólidas.

¿Cómo se sabe que se ha encontrado la causa raíz? Cuando es algo que se puede cambiar, explica dónde y cuándo ocurre el problema y dónde no, y una prueba pequeña que la elimina reduce el problema de forma medible.

Por dónde seguir

Las cuatro guías que más vas a usar son los cinco porqués, el diagrama de Ishikawa, el análisis de Pareto y el árbol de problemas. Una vez conocida la causa, conviértela en un encargo preciso con cómo redactar un enunciado del problema, y consulta el mapa completo de métodos en qué herramienta de innovación usar.