Pregunta editorial¿En qué momento el nombre que damos a un problema empieza a fabricar la solución que vamos a comprar?
Reflexión del diálogoEl problema llega con un nombre y de inmediato queda atrapado. «Esto es cloud migration»: se presupuestan nubes. «Esto es AI adoption»: se compran herramientas de IA. «Esto es Lean»: se hace Lean. «Esto es gestión del cambio»: se financian comunicaciones, formación y gestión de stakeholders. Es posible que esas acciones sirvan. Lo peligroso es que el marco metodológico sustituya la investigación de aquello que no funciona. La empresa deja de preguntar qué necesita y empieza a completar el programa que ya ha sido autorizado.
El documento de reframing despliega otros marcos igual de concretos: quién tiene derecho a definir la verdad; en qué partida presupuestaria puede caber una acción; qué llama éxito cada departamento; qué riesgo consigue dueño; qué historia del mercado permite actuar sin justificar demasiado. «Compliance» puede ver un expediente perfecto, Operaciones una línea parada y Finanzas un coste inexplicable. Todos pueden tener razón dentro de sus columnas y, al mismo tiempo, nadie estar resolviendo el mismo problema.
Esta no es una invitación a despreciar disciplinas, presupuestos o cumplimiento. Se trata de introducir una pausa anterior a la receta: ¿qué observación del terreno obligaría a cambiar el nombre del problema? El marco correcto no es el más moderno ni el que permite comprar más rápido, sino aquel cuya definición sobrevive al contraste con el funcionamiento real del sistema.
About this text
Reflection reconstructed from conversations and writings by Iván Abril Palma. Quotations are distinguished from the editorial development.
Conversación sobre los marcos que autorizan soluciones; jubap.org y reframing.docx · 05/06/2026; escrito privado de reframing