Pensamiento estructurado: la ventaja real del consultor

El pensamiento estructurado es la forma en que un consultor pasa de un problema de cliente vago y confuso a una recomendación que la sala puede seguir y cuestionar. Usted encuadra la decisión, divide el problema en partes que no se solapan, pone a prueba primero la respuesta más probable y reúne los hallazgos en una recomendación clara.

Este texto es para consultores y analistas que quieren una forma repetible de hacerlo bajo presión. Recoge las cuatro herramientas en las que más me apoyo, una hoja de trabajo de una página que puede usar en su próximo encargo y lo que la IA ha cambiado en esta habilidad.

He visto a gente quedarse paralizada en reuniones con clientes. No porque no tuviera ideas. Porque no sabía por dónde empezar.

La escena es conocida. Un problema complejo, una sala llena de directivos, un alcance difuso y la expectativa de claridad. La respuesta sin estructura es ponerse a hablar y esperar a que surja la solución. A veces surge. Con más frecuencia se da vueltas durante veinte minutos y nadie sale satisfecho.

Es la práctica de dividir un problema ambiguo en sus partes, trabajar cada una en orden y volver a reunir los hallazgos en una recomendación.

No es rellenar una plantilla y llamarlo análisis. No es forzar un marco sobre un problema al que no encaja. Un consultor que aplica una matriz 2x2 a todas las situaciones reconoce patrones, no piensa.

Lo que se construye es un conjunto de capacidades:

1. Detectar el problema real, que a menudo es distinto del que se plantea
2. Dividirlo en partes que se puedan analizar por separado
3. Saber qué información importa y cuál no
4. Construir un argumento coherente a partir de lo que se encuentra
5. Decirlo con claridad cuando la sala está tensa

Los marcos son andamiaje mientras esas capacidades se desarrollan. Si quiere el conjunto de herramientas más amplio, explico los más comunes en marcos de consultoría sencillos explicados.

La pregunta de encuadre

Antes de cualquier marco, haga una pregunta. ¿Qué decisión hay que tomar y qué información cambiaría esa decisión?

Hace más por la calidad del análisis que cualquier herramienta estructural. Obliga a aclarar cuál es el resultado y evita que haga un trabajo minucioso sobre una pregunta que nadie necesitaba responder. HBR defendió lo mismo hace años en Are You Solving the Right Problem?: la mayor parte del esfuerzo desperdiciado empieza con un problema mal definido.

En un contexto SAP, «qué modelo de despliegue encaja con esta organización» es una decisión. «Qué es S/4HANA» es una descripción. La primera necesita análisis. La segunda necesita documentación. Saber cuál de las dos está haciendo decide cómo gasta la semana.

MECE

MECE son las siglas en inglés de Mutually Exclusive, Collectively Exhaustive: mutuamente excluyente y colectivamente exhaustivo. Cuando se divide un problema en partes, cada parte debe ser distinta (sin solapamientos) y juntas deben cubrir todo el problema (sin huecos).

Las categorías que se solapan cuentan dos veces. Los huecos dejan cosas fuera. La mayoría de los consultores conoce la sigla. Pocos la aplican con rigor.

Dos pruebas lo mantienen honesto. Primera: ¿podría un elemento estar en dos ramas a la vez? Entonces las ramas se solapan. Segunda: si se respondiera cada rama, ¿quedaría respondida también la pregunta central? Si no, hay un hueco. El MECE perfecto es raro. Lo que importa es hacerse las dos preguntas cada vez.

Árboles de problemas

Un árbol de problemas coloca la pregunta central en la raíz y las subpreguntas en las ramas. Cada rama se puede analizar por separado.

Tome «¿Por qué este go-live de SAP superó en un 40 % el presupuesto previsto?». La primera división podría ser cambios de alcance, costos de recursos, ampliaciones de plazo y correcciones imprevistas. Los cambios de alcance se dividen a su vez en solicitudes de cambio formales, añadidos informales y huecos descubiertos tarde. Cada hoja se puede medir.

Los árboles de problemas valen su peso al principio de un encargo, antes de haber hecho ningún análisis. Evitan que dedique tres semanas a una rama mientras otra queda sin tocar.

Análisis basado en hipótesis

En lugar de reunir todos los datos y concluir después, se parte de la respuesta más probable y se pone a prueba. Las firmas de estrategia construyeron su reputación con este enfoque.

Con poco tiempo y un problema complejo, el análisis exhaustivo no es posible. Una buena hipótesis le dice qué mirar primero. Si se sostiene, ya tiene su respuesta. Si falla, la evidencia que la rompió suele apuntar a algo útil.

También es el enfoque que más se usa mal. Los consultores formulan una hipótesis y luego buscan solo evidencia que la confirme. Pregúntese qué evidencia demostraría que se equivoca y vaya a buscar esa primero.

Esta es la secuencia que entregaría a un consultor nuevo antes de su primer diagnóstico. Rellénela antes de abrir una sola hoja de cálculo.

1. 01EncuadrarLa decisión, en una frase
2. 02DescomponerDe tres a cinco preguntas MECE
3. 03Plantear hipótesisUna línea por rama
4. 04RefutarEvidencia que demostraría que se equivoca
5. 05ComprobarHallazgos por rama, con fuentes
6. 06SintetizarPrimero la recomendación, luego el respaldo
7. 07Probar bajo presiónObjeciones respondidas antes de que las plantee la sala

Una recomendación que sobrevive al comité directivo

Paso	Pregunta que hay que responder	Resultado	Quién lo aprueba
1. Encuadrar	¿Qué decisión necesita tomar el cliente y para cuándo?	Una frase	El patrocinador del cliente
2. Descomponer	¿Qué tres a cinco preguntas, respondidas juntas, resuelven esa decisión?	Árbol de problemas de primer nivel, comprobado con MECE	El responsable del encargo
3. Plantear hipótesis	¿Qué creo ahora que es la respuesta, y por qué?	Una hipótesis de una línea por rama	El responsable del encargo
4. Refutar	¿Qué evidencia demostraría que cada hipótesis es errónea?	Lista de solicitud de datos, priorizada	Los propietarios de los datos del cliente aceptan facilitarla
5. Comprobar	¿Qué dice la evidencia?	Hallazgos por rama, con fuentes	Los responsables de cada rama en el equipo
6. Sintetizar	Entonces, ¿qué debería hacer el cliente?	Primero la recomendación, luego los puntos que la respaldan	El responsable del encargo
7. Probar bajo presión	¿Quién en la sala va a discrepar, y en qué?	Objeciones y respuestas, preparadas	Un colega que no participó en el trabajo

El paso 7 es el que la gente se salta. También es el que decide si la recomendación sobrevive al comité directivo.

Un cliente de SAP, un gran grupo industrial, operaba un entorno ECC muy personalizado. El responsable de TI lo planteó sin rodeos: «Tenemos que reducir los costos operativos, pero no podemos permitirnos romper nada».

El instinto es empezar a enumerar ideas de ahorro. Eso da una lista larga, mucha gente nerviosa y ninguna prioridad.

Organizamos el análisis de costos en tres ramas: mantenimiento de aplicaciones, infraestructura y licencias. Después añadimos el análisis del código personalizado. ¿Cuántas modificaciones se usaban realmente? Más de la mitad no. Interfaces redundantes, informes personalizados sin uso, flujos de trabajo superpuestos.

Estructurarlo así nos permitió señalar ahorros que parecían seguros, como archivar objetos personalizados sin uso y consolidar los entornos de desarrollo. La claridad redujo la fricción política y generó confianza. Sin el árbol, habría sido una lista de recortes que nadie quería firmar.

El mismo método sirve para encargos más vagos. Un proveedor de software empresarial nos pidió una vez «una estrategia de lanzamiento regional» para el segmento de empresas medianas de Arabia Saudita. Dividimos el trabajo en demanda del mercado, posición competitiva y preparación de los socios. Dentro de la preparación de los socios descubrimos que su red de revendedores tenía poca experiencia con SAP S/4HANA Cloud. Ese obstáculo habría paralizado la ejecución por atractivo que pareciera el mercado, y la estructura lo sacó a la luz antes de que gastaran el presupuesto de la campaña.

Los marcos no cambiaron. Cambiaron otras dos cosas.

El borrador ahora es barato. Joule, ChatGPT y Claude producen un árbol de problemas o un árbol de hipótesis en segundos. Los consultores junior que antes dedicaban una tarde a un primer borrador lo generan ahora en medio minuto y dedican la tarde a lo que el modelo no puede hacer: comprobar si la estructura encaja con el problema, encontrar lo que se le escapó y cuestionar los supuestos del prompt.

La prima por criterio creció. Cuando cualquiera puede generar un desglose MECE, la pregunta deja de ser «¿descompuso el problema?». Pasa a ser «¿se dio cuenta de que el problema que declara el cliente es otro y detectó el supuesto que el modelo aceptó por defecto?». Los consultores que han formado su criterio en proyectos reales llevan hoy más ventaja que en 2024.

Así que la habilidad se ha desplazado. Ya no es «¿sabe construir un árbol de problemas?». Es «¿sabe detectar cuándo el árbol redactado por la IA está mal y corregirlo en una sala con el cliente?».

Si está calculando qué lugar deja eso a su propia carrera, las trayectorias profesionales de SAPopedia recogen las rutas de la consultoría, y el pack de carrera de ERPCV le ayuda a mostrar este tipo de criterio en un currículo en lugar de limitarse a enumerar marcos.

Empezar por una solución. El cliente o el consultor tiene una respuesta en mente antes de encuadrar el problema. El análisis se convierte en confirmación.

Demasiada estructura. Algunos problemas sencillos merecen una respuesta directa, no una descomposición MECE. Saber cuándo no usar estructura importa tanto como saber cómo usarla.

Descomponer a la profundidad equivocada. Los árboles que bajan demasiado hondo demasiado pronto producen parálisis. Los que se quedan superficiales producen recomendaciones que nadie puede ejecutar. Ajuste la profundidad a la decisión y al tiempo disponible.

Análisis sin síntesis. Un árbol riguroso que acaba en un volcado de datos. La estructura le ayuda a pensar. El criterio produce la recomendación.

Confundir la estructura de la comunicación con la estructura del pensamiento. Presentar primero la conclusión, como en el Principio de la Pirámide de Barbara Minto, es una técnica de comunicación. No dice nada sobre si el pensamiento de fondo era sólido. Comunicar bien un mal análisis sigue siendo un mal análisis.

Es una habilidad, no un rasgo. Viene con la práctica.

Después de cada conversación importante con un cliente, escriba el problema tal como lo entiende, su descomposición, su hipótesis y la evidencia que la pondría a prueba. Hágalo antes de mirar ningún dato. Escribir obliga a una claridad que pensar en la cabeza no logra.

Practique la síntesis, no solo el análisis. Tomar un montón de evidencia y producir una única recomendación defendible es la mitad más difícil. La mayoría de los consultores junior son adecuados en análisis y poco desarrollados en síntesis. Ahí está el siguiente ascenso, y es una gran parte de lo que los consultores hacen de verdad cuando se quita la jerga vacía.

¿Qué es el pensamiento estructurado en la consultoría?

Es dividir un problema complejo y ambiguo en partes, trabajar cada parte en orden y combinar los hallazgos en una recomendación clara. Hace abordables los problemas difíciles y hace visible el razonamiento, de modo que el cliente puede seguirlo y cuestionarlo en lugar de aceptar una conclusión por fe.

Las herramientas principales son la pregunta de encuadre, los árboles de problemas, MECE y el análisis basado en hipótesis. Ninguna sustituye al criterio.

¿Qué significa MECE y cómo se usa?

Son las siglas en inglés de Mutually Exclusive, Collectively Exhaustive: mutuamente excluyente y colectivamente exhaustivo. Las partes de un desglose no deben solaparse y, juntas, deben cubrir todo el problema.

Prueba de solapamiento: ¿podría un elemento estar en dos ramas? Prueba de huecos: si se respondiera cada rama, ¿quedaría respondida la pregunta central? Aplíquelo al construir el árbol de problemas. Aplicarlo a un análisis terminado suele ser tarde.

¿Cómo funciona el análisis basado en hipótesis?

Se enuncia pronto la respuesta más probable, se enumera la evidencia que la confirmaría o la refutaría y luego se pone a prueba. Es más rápido que reunirlo todo primero porque indica dónde mirar.

El riesgo es el sesgo de confirmación. Busque primero la evidencia que podría demostrar que se equivoca.

¿Cómo se encuadra correctamente un problema de consultoría?

Pregunte qué decisión hay que tomar y qué información la cambiaría. Después ponga a prueba el enunciado del problema del cliente antes de aceptarlo.

Un cliente que pregunta «¿qué módulo de SAP deberíamos implementar primero?» puede estar decidiendo en realidad «¿es este el momento adecuado para iniciar un programa SAP?». Responder a la pregunta planteada sin poner a prueba el encuadre da un análisis técnicamente correcto y comercialmente equivocado.

¿Cuál es la diferencia entre análisis y síntesis en la consultoría?

El análisis divide un problema o un conjunto de datos en partes para entenderlas. La síntesis combina los hallazgos en una recomendación.

El fallo más común en un entregable es mucho análisis y ninguna síntesis: el cliente recibe una pila de hallazgos y ninguna respuesta a la pregunta por la que le contrató. Escribir primero la conclusión obliga a que la síntesis ocurra.

¿Cómo se aplica el pensamiento estructurado a las implementaciones de ERP?

Al inicio del programa evita que los equipos configuren antes de entender el problema real. Una organización que dice «necesitamos SAP» puede tener que arreglar antes un proceso o un problema de datos que SAP solo hará más visible.

En el trabajo de fit-gap, un desglose MECE de los procesos de negocio garantiza que se considere cada proceso, no solo los que se plantearon en los talleres. Tras un go-live problemático, encuadrar la decisión (estabilizar, recuperar o sustituir) y poner a prueba una hipótesis sobre la causa principal lleva a una recomendación defendible más rápido que enumerar síntomas.