🧭 Un mapa de causas no es un diagnóstico
He publicado una herramienta gratuita para construir mapas de causas. Está hecha desde una idea incómoda: el mapa no demuestra nada, solo ordena lo que falta por comprobar.
En muchas reuniones de análisis el dibujo se termina antes que la conversación. Alguien traza las ramas, el grupo rellena los huecos durante veinte minutos y al final aparece una causa que convence a todo el mundo. A partir de ese momento el mapa deja de ser una herramienta de investigación y pasa a ser el acta que justifica lo que ya se iba a hacer.
He publicado una herramienta gratuita para construir estos mapas: Mapa de causas. Está hecha desde una idea incómoda: un mapa de causas no demuestra nada. Solo ordena lo que falta por comprobar.
El punto exacto donde el mapa se convierte en diagnóstico
El salto ocurre siempre en el mismo sitio. Una rama suena razonable, nadie la discute, y lo razonable se adopta como verdad sin pasar por ningún dato. No hace falta mala fe: basta con que la hipótesis encaje con lo que el grupo ya sospechaba.
El coste de ese salto no se ve en la reunión. Se ve tres meses después, cuando el problema vuelve con otro nombre y alguien dice que esto ya lo habíamos analizado.
Una causa raíz (root cause) no es la explicación que más convence. Es la que, si la eliminas, hace desaparecer el problema. Y eso solo se sabe comprobándolo.
La pregunta que convierte una rama en trabajo
Hay una pregunta que cambia por completo el valor de un mapa de causas, y conviene hacerla rama por rama:
¿Qué dato tendría que ver para descartar esta hipótesis?
Si la pregunta no tiene respuesta, la rama no es una hipótesis: es una opinión con forma de diagrama. Si la tiene, el mapa acaba de generar trabajo concreto, con un dato que buscar y alguien que lo busque.
La herramienta obliga a ese paso: cada causa que propone llega con su pregunta de verificación ya escrita, no como adorno, sino porque el paso siguiente es ir a mirar, no decidir.
Qué hace la herramienta
- Genera un mapa de hipótesis causales a partir de un problema descrito en lenguaje normal, adaptado al sector.
- Despliega el mapa de izquierda a derecha, con el problema anclado a la izquierda y las causas abriéndose por niveles.
- Permite editar, añadir, reordenar y eliminar cualquier causa: lo que propone es un punto de partida, no un resultado.
- Registra el estado de cada hipótesis: sin verificar, con evidencia a favor o descartada, con la evidencia recogida y quién la busca.
- Sugiere mecanismos Poka-yoke contextuales cuando en la causa se identifica un mecanismo de error concreto.
- Exporta en PNG, en SVG y en Excel, con una hoja de registro para repartir la investigación entre varias personas.
- Guarda el proyecto en un archivo y lo vuelve a abrir, para retomarlo cuando lleguen los datos.
Tres hipótesis descartadas con datos valen más que una lista de diez que nadie ha mirado. Descartar también es avanzar, y es la parte que casi ningún análisis documenta.
Lo que se ahorra cuando la hipótesis se verifica antes
Saltarse la comprobación no es neutro. Genera desperdicio (waste) perfectamente identificable, y casi siempre el mismo:
| Desperdicio (waste) | Cómo aparece al saltarse la verificación |
|---|---|
| Sobreproceso | Se rediseña un paso que no era el que fallaba |
| Espera | El equipo espera una solución que no cambia el resultado |
| Defectos | El problema reaparece, porque la causa real sigue en su sitio |
| Movimiento de información | Se recogen datos después de decidir, para justificar la decisión |
| Talento no utilizado | Quien tenía el dato no estaba en la sala, y nadie fue a preguntarle |
El Poka-yoke va después, no antes
Un Poka-yoke es un mecanismo que impide o detecta el error en el punto donde se produce. Por eso no tiene sentido proponerlo sobre una causa que todavía no se ha confirmado: acabas blindando un paso que no era el problema.
La herramienta sugiere mecanismos solo cuando se los pides, causa por causa, y solo cuando en el texto hay un mecanismo de error identificable: un dato que se reintroduce a mano, un criterio que depende de la persona, una cola que crece sin señal. Cuando no lo hay, lo dice y pide más detalle, en lugar de inventarse una recomendación.
Los mecanismos llegan clasificados por nivel de prevención, de eliminar el error a mitigar sus consecuencias, con cómo implementarlo y qué mirar después para saber si ha funcionado. Es el mismo orden que defendí en cuando cada incidente empeora el proceso: prevenir no es añadir un control más.
Cómo usarla en una reunión de verdad
- Escribe el problema tal y como se observa, no como sospecha de causa. «Las facturas salen con errores» es un problema; «el equipo no presta atención» ya es una conclusión.
- Reparte las ramas entre las personas que pueden ir a mirar, no entre las que más opinan.
- Marca como prioritaria la hipótesis cuya comprobación sea más barata, no la que parezca más probable.
- Pon fecha a la verificación, no a la solución.
- Vuelve al mapa con los datos y descarta en voz alta. Esa es la reunión que cambia algo.
Si el mapa se queda en la pared sin que nadie tire de ninguna rama, acaba pasando lo de nadie tiró de esto, que es el final más común de los análisis bien dibujados.
Para qué sirve, en una frase
Un mapa de causas no sirve para tener razón antes de tiempo. Sirve para repartir la duda de forma que se pueda resolver con datos.
La herramienta está publicada y es de uso libre, sin registro: consultoriaprocesos.com/mapa-de-causas.
Si el mapa te sirve para descartar tres hipótesis con datos, ha hecho su trabajo.
Si prefieres trabajarlo con tu equipo sobre vuestros propios problemas, es exactamente el tipo de sesión que hago en formación. Desde Barcelona, para toda España. Trabajo presencial en cualquier punto del país, también con empresas que están fuera de las ciudades, y en remoto cuando tiene más sentido.
