> ## Content Index > Fetch the complete content index at: https://www.consultoriaprocesos.com/llms.txt > Use this file to discover other available public pages before exploring further. # 🧭 ¿Entender mejor el problema, o descubrir qué solución funciona? - URL: https://www.consultoriaprocesos.com/entender-el-problema-o-probar-la-solucion/ - Published: 2026-10-25T11:54:34.000Z - Updated: 2026-10-25T11:54:34.000Z - Description: Ni analizar sin parar ni lanzarse a resolver. Un marco para decidir, en cada momento, cuál es la incertidumbre que toca reducir primero. - Author: Johan - Tags: Consultoría, Metodología La clave está en saber **cuándo entiendes el problema lo suficiente** como para que diseñar soluciones sea productivo. Ni en Lean, ni en el ciclo PDCA, ni en el pensamiento Poka-yoke de Shigeo Shingo el objetivo es analizar sin parar ni lanzarse a resolver. El objetivo es reducir la incertidumbre en el orden correcto. ## **1\. Un marco de decisión práctico** La pregunta de partida es siempre la misma: ¿qué está impidiendo ahora mismo avanzar de verdad? Hay dos respuestas posibles, y cada una manda hacia un sitio distinto. | | Incertidumbre sobre el problema | Incertidumbre sobre la solución | | ----------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Qué nos falta | No sabemos por qué, dónde, cuándo ni en qué condiciones se produce el fallo | Conocemos el mecanismo del fallo, pero no qué contramedida funcionará mejor | | Dónde poner el esfuerzo | Entender | Diseñar y probar | | Qué se hace | Observar, mapear, medir, identificar el punto de error y las condiciones causales | Generar opciones, priorizar, prototipar, experimentar y evaluar | ¿Y si las dos siguen siendo inciertas? Entonces no toca elegir: toca **un experimento pequeño que enseñe sobre ambas a la vez**. ## **2\. Cinco preguntas que te dicen cuándo cambiar de modo** Recórrelas en orden. La primera que conteste «no» marca dónde está el trabajo pendiente. | Pregunta | Si la respuesta es NO | | ------------------------------------------------------------------------ | ----------------------------------------------- | | 1\. ¿Sabemos exactamente qué está yendo mal? | Define el problema y reúne evidencia | | 2\. ¿Sabemos dónde se origina el fallo? | Mapea el proceso e identifica el punto de error | | 3\. ¿Entendemos las condiciones que lo permiten? | Investiga causas, no solo síntomas | | 4\. ¿Sabemos qué tiene que conseguir una mejora para considerarse buena? | Define requisitos y criterios de éxito | | 5\. ¿Podemos ya comparar contramedidas plausibles? | Empieza la ideación y el diseño | No hace falta certeza absoluta en todas. Hace falta **comprensión causal suficiente para no diseñar contramedidas basadas sobre todo en suposiciones**. La cuarta pregunta es la que más veces se salta, y la que más caro sale. De eso hablaba en [si puedes rellenar estas cinco casillas, ya has hecho el análisis](https://www.consultoriaprocesos.com/cinco-casillas-ya-has-hecho-el-analisis/). ## **3\. La distinción de Shingo que más sirve** Piensa en un problema corriente: las solicitudes de cliente llegan con información incorrecta. Mira cómo cambia el enunciado en cada etapa. **Comprensión del problema.** «Las solicitudes de cliente contienen información incorrecta.» Eso describe un defecto, pero no su origen. **Identificación del punto de error.** «Durante la introducción manual de datos, a veces se selecciona la cuenta de cliente equivocada de una lista larga de nombres parecidos.» Ahora sí hay un mecanismo concreto. **Ideación de soluciones.** Contramedidas posibles: escanear un identificador único de cliente, autocompletar desde un registro de referencia, o restringir la selección a coincidencias verificadas. **Experimento y verificación.** Comprobar si la contramedida evita la selección incorrecta sin crear problemas nuevos ni trabajo innecesario. Fíjate en la transición decisiva: **en el momento en que puedes explicar cómo surge el error, puedes empezar a diseñar cómo impedirlo**. Eso es más útil que empeñarse en un análisis de causa raíz (root cause) completo de todo lo que podría estar contribuyendo al problema. El recorrido completo desde ese punto de error hasta el mecanismo lo desarrollé en [nueve preguntas para que un paso deje de poder hacerse mal](https://www.consultoriaprocesos.com/nueve-preguntas-poka-yoke/). ## **4\. Cuatro paradojas que conviene tener presentes** - **Más análisis puede producir menos aprendizaje.** Pasado cierto punto, otro taller u otro diagrama de espina añade menos conocimiento que probar una contramedida pequeña y reversible. - **Una solución puede revelar el problema.** A veces no se entiende del todo el mecanismo del fallo hasta que se prototipa un cambio y se observa qué pasa. El PDCA es iterativo, no estrictamente lineal. - **Un problema bien definido facilita la ideación en lugar de estrecharla.** Conocer el punto de error y las restricciones permite soluciones más creativas, porque sabes qué tiene que cambiar de verdad. - **El entusiasmo por la solución puede esconder una mala comprensión del problema.** Un equipo puede diseñar con ilusión formación, listas de comprobación y cuadros de mando antes de haber establecido por qué ocurre el error. El resultado suele ser más trabajo sin prevención. La cuarta es la que más daño hace a largo plazo, porque cada una de esas respuestas se queda en el proceso para siempre. Es el mecanismo que describí en [cuando cada incidente empeora el proceso](https://www.consultoriaprocesos.com/cuando-cada-incidente-empeora-el-proceso/). ## **5\. Una regla útil para quien facilita** En cualquier momento de un taller de mejora, la pregunta que reordena la sala es esta: > ¿Cuál es la incertidumbre más importante que necesitamos resolver ahora? Y luego, elegir cuál de las cuatro es la que está bloqueando al equipo en ese instante: - ¿Qué está pasando exactamente? - ¿Por qué o dónde está pasando? - ¿Qué contramedida funcionará? - ¿Nuestro cambio ha mejorado algo de verdad? Cada una manda a un sitio distinto, y confundirlas es lo que hace que una sesión de dos horas termine sin nada accionable. ## **6\. La gravedad cambia la secuencia** Hay una excepción que conviene decir en voz alta. Si el incidente afecta a la seguridad, expone a un incumplimiento serio o perjudica de forma importante al cliente, puede hacer falta contención inmediata antes de completar el análisis. La contención protege a las personas y a los clientes ahora. **No es necesariamente la solución definitiva**, y confundir una cosa con la otra es como se acumulan los controles provisionales que duran años. La secuencia pasa a ser: contener, entender, prevenir, verificar, estandarizar. Para una oportunidad de mejora normal, un ciclo más ligero y más rápido suele ser suficiente. ## **La pregunta central, y la que hay debajo** Si tuviera que poner una sola pregunta en el centro de un mapa mental o de un taller, sería esta: **¿necesitamos entender mejor el problema, o saber qué solución funciona?** Y la pregunta más profunda, la de inspiración Shingo, sería esta otra: **¿conocemos las condiciones que permiten que este defecto se cree?** Si no, investiga. Si sí, diseña y prueba. Si hay dudas, experimenta para aprender. > El objetivo no es repartir el tiempo a partes iguales entre analizar el problema y desarrollar la solución. Es gastar el esfuerzo allí donde más reduce la incertidumbre que impide mejorar. Esta forma de ordenar un taller de mejora es parte de lo que trabajo en [formación](https://www.consultoriaprocesos.com/formacion/) y en los procesos de consultoría. 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.