Cómo estructurar un caso de consultoría: el método del árbol de problemas

Antes de aprender a construir una, entiende qué es lo que estás construyendo.

Imagina que eres un bombero que llega a un edificio en llamas. No entras corriendo al azar a echar agua. Primero evalúas el edificio: qué pisos se están quemando, dónde están las salidas, dónde podría haber gente atrapada. Esa evaluación de 30 segundos es tu estructura. Te dice dónde poner los recursos y en qué orden.

La estructura de un caso es lo mismo. Es una evaluación rápida (antes de cualquier análisis) de cómo se ve el espacio del problema. ¿Qué áreas podrían estar causando esto? ¿Qué áreas podemos descartar de inmediato? ¿Dónde está el lugar de más palanca para escarbar primero? La estructura no responde la pregunta. Mapea el territorio para que tu análisis no pierda tiempo en los cuartos equivocados.

Sin ella, eres el bombero que corre a ciegas. Con ella, eres quien encuentra el problema en la mitad del tiempo.

Un árbol de problemas es la herramienta visual que usan los consultores para construir y comunicar la estructura. Así puedes pensarlo.

Eres una detective que acaba de entrar a la escena de un crimen. No buscas huellas en cada superficie. Empiezas con tres preguntas: móvil, medios, oportunidad. Cada una se divide en subpreguntas. El móvil se divide en quién se beneficia de este resultado y quién tenía un agravio. Los medios se dividen en quién tenía acceso y quién tenía la habilidad. Vas bajando por el árbol y eliminas ramas a medida que la evidencia las descarta.

Un árbol de problemas hace exactamente esto con un problema de negocio. La raíz es la pregunta del cliente: "¿Por qué están cayendo nuestras utilidades?". El primer nivel de ramas es la división MECE de las causas posibles: un problema de ingresos, un problema de costos o ambos. Los ingresos se dividen en precio y volumen. El volumen se divide en número de clientes y frecuencia de compra. Cada rama es una hipótesis. Eliminas las que los datos descartan y profundizas en las que los datos respaldan.

El árbol evita que des vueltas en círculos. Cada pregunta que haces corresponde a un nodo. Si una pregunta no corresponde a ningún nodo, o agregas el nodo o descartas la pregunta, porque significa que estás investigando algo fuera del espacio del problema.

El entrevistador te da el planteamiento. Haces una pregunta de aclaración para confirmar el objetivo. Luego dices: "¿Me das un minuto para estructurar mis ideas?". Esto es lo que pasa en ese minuto.

Paso 1: escribe la pregunta del cliente en la parte de arriba de tu hoja. No la situación. La pregunta. "¿Debería Peloton bajar sus precios?", no "El crecimiento de suscriptores de Peloton se está desacelerando".

Paso 2: dibuja de tres a cuatro ramas de primer nivel. Son las grandes categorías MECE del espacio de respuestas. Para un caso de rentabilidad: ingresos y costos. Para un caso de entrada a un mercado: atractivo del mercado, ventaja competitiva y estrategia de salida al mercado. No inventes un framework nuevo para cada caso. Un conjunto pequeño de estructuras de primer nivel confiables cubre 80% de los casos.

Paso 3: agrega un nivel de detalle debajo de cada rama. Los ingresos se dividen en precio y volumen. El volumen se divide en clientes nuevos y retención. Este segundo nivel es lo que le demuestra al entrevistador que conoces el tema, no solo la plantilla.

Paso 4: enuncia una hipótesis. Antes de empezar a pedir datos, comprométete con una teoría de trabajo. "Mi hipótesis es que el problema está del lado de los costos, en concreto en costos fijos que no se han reducido al bajar la demanda, pero primero quiero validarlo con datos de ingresos". Esto es lo que separa a los analistas guiados por hipótesis de los que solo recolectan datos.

Practica esto en el caso de Peloton, un problema de rentabilidad clásico en el que la estructura de ramas entre los costos de hardware, suscripción y contenido revela exactamente qué palanca importa más.

Conocer el método no basta. Estos cuatro errores aparecen en casi todos los primeros borradores.

Error 1: empezar con un framework con nombre en lugar de con el problema. "Voy a usar las 4 P" no es una estructura. Es una plantilla. Los frameworks son insumos, no resultados. Tu estructura debería salir de la pregunta específica del cliente, no de una lista memorizada.

Error 2: ramas de primer nivel que no son MECE. "Ingresos, costos y margen bruto" tiene traslapes. El margen bruto incluye los ingresos. Si un dato podría caber en dos ramas, tu estructura está rota antes de que empiece el análisis.

Error 3: demasiadas ramas. De tres a cuatro ramas de primer nivel es el límite. Con más de cuatro, describiste el problema en lugar de estructurarlo. Si tienes seis ramas, dos deberían fusionarse o eliminarse.

Error 4: saltarte la hipótesis. Una estructura sin hipótesis es solo una lista. La hipótesis es lo que convierte el árbol en una herramienta. Te dice qué rama investigar primero y qué resultado te haría cambiar de opinión.

La estructura de un caso es un músculo. Se construye haciéndolo, no leyendo sobre ello.

Ejercicio 1: estructura un titular de noticias. Elige cualquier noticia de negocios y construye un árbol de problemas de primer nivel para el problema que describe. "El tráfico de Starbucks cayó 8% frente al año anterior". Dibuja el árbol antes de leer el artículo. Luego compara qué tan cerca estuviste.

Ejercicio 2: oblígate a llegar a una hipótesis. Después de dibujar cualquier estructura, escribe una oración que empiece con "Mi hipótesis es..." antes de permitirte pedir datos. Si no puedes formular una hipótesis, tu estructura no es lo bastante específica.

Ejercicio 3: practica con un caso que se resista. La mejor forma de poner a prueba una estructura es usarla bajo presión, con un caso que tenga datos reales, callejones sin salida y giros que castiguen una estructura inicial débil. Eso es lo que construye la práctica de casos realista.