Preguntas de entrevista Consultor de gestión

Empezaría estructurando el problema antes de tocar ningún dato. El beneficio es ingresos menos costes, así que dividiría mi hipótesis inicial en dos ramas: ¿es un problema de ingresos, de costes, o de ambos? Para los ingresos examinaría volumen, precio y mix. Para los costes separaría fijos de variables y comprobaría si los costes unitarios han cambiado. Luego pediría al entrevistador los datos más capaces de confirmar o descartar cada rama rápidamente. En un proyecto real construiría este árbol de problemas el primer día y me alinearía con el cliente antes de profundizar en ninguna área. El objetivo es pasar las primeras 48 horas reduciendo el espacio de hipótesis, no analizándolo todo a la vez. Una estructura clara al principio ahorra semanas de análisis innecesario.

Comienzo con la recomendación, no con el análisis. Los altos directivos quieren saber qué hacer y por qué importa antes de saber cómo llegué a esa conclusión. En la práctica eso significa que mi primera diapositiva expone la recomendación con claridad, la segunda cubre los tres argumentos de apoyo más sólidos y la tercera aborda las objeciones más probables. Mantengo los gráficos simples: un mensaje por gráfico, etiquetado para que la conclusión sea visible sin leer el cuerpo del texto. También anticipo las preguntas que hará el CFO o el COO y preparo una diapositiva de apéndice por objeción clave para poder responder de inmediato. Practico decir la recomendación en voz alta en una sola frase antes de cualquier presentación importante.

Lo trato como el momento más valioso del análisis. Si los datos contradicen la hipótesis, o bien la hipótesis era incorrecta o los datos tienen un problema de calidad. Mi primer paso es verificar los datos: fuente, fecha, cómo se recopilaron y si son internamente coherentes. Si los datos son sólidos, actualizo la hipótesis y comunico el cambio con claridad al equipo y al cliente. No me aferro a una hipótesis por apego. En un proyecto había construido un modelo de tamaño de mercado que mostraba un potencial de crecimiento significativo, pero los datos de transacciones del cliente mostraban la tendencia contraria. En lugar de ignorar la discrepancia, la investigué y descubrí que los datos de mercado excluían un canal de distribución importante. Ese hallazgo cambió toda la recomendación estratégica.

En mi empresa anterior trabajaba con un director financiero abiertamente escéptico sobre el proyecto que cuestionaba cada hallazgo intermedio. En lugar de escalar, solicité una reunión individual al comienzo de la segunda semana para entender sus preocupaciones directamente. Me explicó que la última consultora había hecho promesas que no cumplió y dejó al equipo con más trabajo. Reconocí ese historial y acordé compartir un documento de trabajo con nuestros hallazgos cada viernes en lugar de esperar a un entregable formal. En tres semanas la dinámica cambió: empezó a señalar fuentes de datos de forma proactiva e incluso respaldó nuestra recomendación en la presentación final al consejo. La resistencia del cliente suele venir de experiencias previas, no del trabajo actual.

Durante un proyecto de transformación de costes, mi análisis mostró que la unidad de negocio más rentable del cliente estaba subvencionando significativamente a tres divisiones con bajo rendimiento. El CEO se había comprometido públicamente a desarrollar las cuatro divisiones. Sabía que el hallazgo sería incómodo. Preparé un resumen conciso de una página con las evidencias, el impacto financiero cuantificado con claridad y dos opciones estratégicas en lugar de una única diapositiva de "aquí está el problema". Informé a la patrocinadora del proyecto en privado antes de la reunión del consejo para que no se llevara sorpresas, y enmarqué los hallazgos como decisiones que el equipo directivo ahora podía tomar con información, no como un veredicto sobre decisiones pasadas. La CEO dijo que ese enfoque fue la razón por la que el consejo reaccionó de forma constructiva.

En un proyecto de integración post-fusión, los equipos de operaciones y comercial tenían visiones fundamentalmente distintas sobre qué sistemas consolidar primero. Operaciones quería priorizar el ERP para reducir costes rápidamente. Comercial quería mantener el CRM intacto para proteger las relaciones con los clientes durante la transición. Mapeé la preocupación central de cada grupo y el riesgo que intentaba evitar, luego diseñé una propuesta de secuenciación que preservaba el CRM durante los primeros seis meses mientras comenzaba la consolidación del ERP en las funciones de back-office sin exposición al cliente. Lo presenté como un camino de gestión de riesgos, no como un compromiso, mostrando el impacto en costes y plazos de cada secuencia. Ambos equipos aceptaron.

Trabajo partiendo de la hipótesis. Antes de pedir datos escribo lo que espero encontrar y qué me haría cambiar de opinión. Esa disciplina mantiene el análisis enfocado: estoy probando afirmaciones concretas, no buscando algo interesante. Para el análisis cuantitativo normalmente construyo un modelo en Excel que traza el camino desde los datos primarios hasta la conclusión final, con cada hipótesis documentada y sometida a análisis de sensibilidad. Para los datos cualitativos uso entrevistas estructuradas con un conjunto de preguntas coherente para identificar patrones en lugar de depender de anécdotas individuales. Siempre triangulo: una fuente de datos que confirma un hallazgo me da una hipótesis, dos fuentes independientes me dan confianza, tres me dan una recomendación que estoy dispuesto a defender ante un consejo de administración.

Estructuro un caso de negocio en torno a tres preguntas: cuál es la oportunidad, cuánto cuesta capturarla y cuáles son los riesgos. Para la oportunidad cuantifico el valor disponible usando datos de mercado, referencias internas o estudios de casos comparables según lo disponible. Para los costes separo el gasto de capital del gasto operativo y distingo los costes de implementación puntuales de los costes de funcionamiento continuos. Para el modelo financiero proyecto los flujos de caja a tres o cinco años, calculo el VAN y la TIR, e incluyo un período de recuperación porque suele ser la métrica en la que los directivos se centran primero. La sección de riesgos cubre los dos o tres supuestos en los que se basa todo el caso de negocio y qué ocurre con los rendimientos si esos supuestos están equivocados en un 20%.

MECE, mutuamente excluyente y colectivamente exhaustivo, es la disciplina que aplico cuando construyo un árbol de problemas. El objetivo es dividir el problema en partes que no se superponen y que juntas cubren todas las causas posibles. En la práctica comienzo identificando las una o dos dimensiones que separan con más claridad el espacio del problema. Para un problema de ingresos podría ser nuevos clientes frente a clientes existentes, o línea de producto A frente a línea de producto B. Luego pongo a prueba cada rama: si abordara esta rama por completo, ¿habría explicado una parte significativa del problema? Si las ramas se superponen, rediseño el árbol. El árbol de problemas es una herramienta de pensamiento, no una plantilla de presentación: debe ser probado antes de compartirlo con un cliente.