Pensamento estruturado: a vantagem real do consultor

Pensamento estruturado é como um consultor sai de um problema vago e confuso do cliente e chega a uma recomendação que a sala consegue acompanhar e questionar. Você enquadra a decisão, divide o problema em partes que não se sobrepõem, testa primeiro a resposta mais provável e depois reúne as conclusões em uma única recomendação clara.

Este texto é para consultores e analistas que querem um jeito repetível de fazer isso sob pressão. Ele cobre as quatro ferramentas em que mais me apoio, um roteiro de uma página que você pode usar no seu próximo projeto e o que a IA mudou nessa habilidade.

Já vi pessoas travarem em reuniões com clientes. Não porque não tivessem ideias. Porque não sabiam por onde começar.

O cenário é conhecido. Um problema complexo, uma sala cheia de gente sênior, um escopo vago e a expectativa de clareza. A resposta sem estrutura é começar a falar e torcer para que a resposta apareça. Às vezes aparece. Mais vezes você fica dando voltas por vinte minutos e ninguém sai satisfeito.

É a prática de dividir um problema ambíguo em partes, trabalhar cada parte em ordem e reunir as conclusões em uma recomendação.

Não é preencher um modelo e chamar isso de análise. Não é forçar um framework sobre um problema ao qual ele não se aplica. O consultor que aplica uma matriz 2x2 a toda situação está apenas encaixando padrões, não pensando.

O que você está construindo é um punhado de habilidades:

1. Identificar o problema real, que muitas vezes é diferente do apresentado
2. Dividi-lo em partes que podem ser analisadas separadamente
3. Saber quais informações importam e quais não
4. Construir um argumento coerente a partir do que você encontra
5. Dizê-lo com clareza quando a sala está tensa

Os frameworks são andaimes enquanto essas habilidades se desenvolvem. Se você quer o conjunto mais amplo de ferramentas, abordo os mais comuns em frameworks de consultoria simples, explicados.

A pergunta de enquadramento

Antes de qualquer framework, faça uma pergunta. Que decisão precisa ser tomada e que informação mudaria essa decisão?

Ela faz mais pela qualidade da análise do que qualquer ferramenta estrutural. Obriga a deixar claro qual é o resultado esperado e impede que você faça um trabalho minucioso sobre uma pergunta que ninguém precisava ver respondida. A HBR defendeu a mesma ideia anos atrás em Are You Solving the Right Problem?: a maior parte do esforço desperdiçado começa com um problema mal definido.

Em um contexto SAP, “qual modelo de implantação serve a esta organização” é uma decisão. “O que é o S/4HANA” é uma descrição. A primeira precisa de análise. A segunda precisa de documentação. Saber qual das duas você está fazendo decide como você vai gastar a semana.

MECE

MECE vem de Mutually Exclusive, Collectively Exhaustive: mutuamente exclusivo, coletivamente exaustivo. Quando você divide um problema em partes, cada parte deve ser distinta (sem sobreposição) e, juntas, elas devem cobrir o problema inteiro (sem lacunas).

Categorias que se sobrepõem contam em dobro. Lacunas deixam coisas de fora. A maioria dos consultores conhece a sigla. Poucos a aplicam com rigor.

Dois testes mantêm o método honesto. Primeiro: um item poderia estar em dois ramos ao mesmo tempo? Então os ramos se sobrepõem. Segundo: se todos os ramos fossem respondidos, a pergunta central também seria respondida? Se não, há uma lacuna. MECE perfeito é raro. O que importa é fazer as duas perguntas todas as vezes.

Árvores de questões

Uma árvore de questões coloca a pergunta central na raiz e as subperguntas nos ramos. Cada ramo pode ser analisado separadamente.

Tome a pergunta “Por que este go-live do SAP estourou em 40% o orçamento previsto?” A primeira divisão pode ser mudanças de escopo, custos de recursos, extensões de cronograma e correções não planejadas. As mudanças de escopo se dividem, por sua vez, em solicitações formais de mudança, acréscimos informais e lacunas descobertas tarde. Cada folha pode ser medida.

As árvores de questões se pagam no início de um projeto, antes de você ter feito qualquer análise. Elas impedem que você passe três semanas em um ramo enquanto outro fica intocado.

Análise orientada por hipóteses

Em vez de reunir todos os dados e só então concluir, você começa pela resposta mais provável e a testa. As consultorias de estratégia construíram a reputação com essa abordagem.

Com tempo limitado e um problema complexo, a análise exaustiva não é possível. Uma boa hipótese diz o que olhar primeiro. Se ela se sustenta, você tem a sua resposta. Se cai, a evidência que a derrubou costuma apontar para algum lugar útil.

É também a abordagem mais usada de forma errada. Os consultores formam uma hipótese e depois procuram apenas evidências que a confirmem. Pergunte que evidência provaria que você está errado e vá procurá-la primeiro.

Esta é a sequência que eu entregaria a um consultor novo antes do primeiro diagnóstico. Preencha-a antes de abrir uma única planilha.

1. 01EnquadrarA decisão, em uma frase
2. 02DecomporTrês a cinco perguntas MECE
3. 03Formular hipótesesUma linha por ramo
4. 04RefutarEvidências que provariam que você está errado
5. 05TestarConclusões por ramo, com as fontes
6. 06SintetizarPrimeiro a recomendação, depois o embasamento
7. 07Pôr à provaObjeções respondidas antes de a sala levantá-las

Uma recomendação que sobrevive ao comitê de direção

Passo	Pergunta a responder	Resultado	Quem aprova
1. Enquadrar	Que decisão o cliente precisa tomar e até quando?	Uma frase	O patrocinador do cliente
2. Decompor	Quais três a cinco perguntas, respondidas em conjunto, resolvem essa decisão?	Árvore de questões de primeiro nível, testada quanto ao MECE	Líder do projeto
3. Formular hipóteses	O que eu acredito neste momento que seja a resposta, e por quê?	Uma hipótese de uma linha por ramo	Líder do projeto
4. Refutar	Que evidência mostraria que cada hipótese está errada?	Lista de solicitação de dados, priorizada	Os responsáveis pelos dados do cliente concordam em fornecê-los
5. Testar	O que a evidência diz?	Conclusões por ramo, com as fontes	Responsáveis por cada ramo na equipe
6. Sintetizar	Então, o que o cliente deve fazer?	Primeiro a recomendação, depois os pontos de apoio	Líder do projeto
7. Pôr à prova	Quem na sala vai discordar, e em quê?	Objeções e respostas, preparadas	Um colega que não participou do trabalho

O passo 7 é o que as pessoas pulam. É também o passo que decide se a recomendação sobrevive ao comitê de direção.

Um cliente SAP, um grande grupo industrial, rodava um ambiente ECC muito customizado. O líder de TI foi direto: “Precisamos cortar custos operacionais, mas não podemos nos dar ao luxo de quebrar nada.”

O instinto é começar a listar ideias de economia. Isso dá uma lista longa, muita gente nervosa e nenhuma prioridade.

Organizamos a análise de custos em três ramos: manutenção de aplicações, infraestrutura e licenciamento. Depois acrescentamos a análise do código customizado. Quantas modificações estavam realmente em uso? Mais da metade não estava. Interfaces redundantes, relatórios customizados sem uso, fluxos de trabalho sobrepostos.

Estruturar a análise assim nos permitiu apontar economias que pareciam seguras, como arquivar objetos customizados sem uso e consolidar ambientes de desenvolvimento. A clareza reduziu o atrito político e gerou confiança. Sem a árvore, teria sido uma lista de cortes que ninguém queria assinar.

O mesmo método funciona com pedidos mais vagos. Um fornecedor de software corporativo nos pediu uma vez “uma estratégia de lançamento regional” para o segmento de médias empresas da Arábia Saudita. Dividimos o trabalho em demanda de mercado, posição competitiva e prontidão de parceiros. Em prontidão de parceiros, descobrimos que a rede de revendedores deles tinha pouca experiência com o SAP S/4HANA Cloud. Esse bloqueio teria paralisado a execução por mais atraente que o mercado parecesse, e a estrutura o revelou antes que gastassem o orçamento da campanha.

Os frameworks não mudaram. Duas outras coisas mudaram.

O rascunho agora é barato. O Joule, o ChatGPT e o Claude produzem uma árvore de questões ou uma árvore de hipóteses em segundos. Consultores juniores que antes passavam uma noite em um primeiro rascunho agora o geram em meio minuto e gastam a noite no que o modelo não faz: testar se a estrutura se ajusta ao problema, encontrar o que ficou de fora e questionar as premissas do prompt.

O prêmio do julgamento aumentou. Quando todo mundo consegue gerar uma decomposição MECE, a pergunta deixa de ser “você decompôs o problema?”. Passa a ser “você percebeu que o problema declarado pelo cliente é outro problema e pegou a premissa que o modelo aceitou por padrão?”. Os consultores que construíram julgamento em projetos reais têm hoje uma vantagem maior do que tinham em 2024.

Então a habilidade se deslocou. Já não é “você sabe montar uma árvore de questões?”. É “você sabe dizer quando a árvore rascunhada pela IA está errada e corrigi-la em uma sala com o cliente?”.

Se você está avaliando o que isso significa para a sua própria carreira, os caminhos de carreira da SAPopedia mapeiam as trilhas da consultoria, e o pacote de carreira da ERPCV ajuda a mostrar esse tipo de julgamento em um currículo, em vez de apenas listar frameworks.

Começar por uma solução. O cliente ou o consultor tem uma resposta em mente antes de o problema ser enquadrado. A análise vira confirmação.

Estrutura demais. Alguns problemas simples merecem uma resposta direta, não uma decomposição MECE. Saber quando não usar estrutura importa tanto quanto saber usá-la.

Decompor na profundidade errada. Árvores que descem fundo demais cedo demais produzem paralisia. Árvores que ficam rasas produzem recomendações em que ninguém consegue agir. Ajuste a profundidade à decisão e ao tempo disponível.

Análise sem síntese. Uma árvore rigorosa que termina em um despejo de dados. A estrutura ajuda você a pensar. O julgamento produz a recomendação.

Confundir a estrutura de comunicação com a estrutura de raciocínio. Apresentar a conclusão primeiro, como no Princípio da Pirâmide de Barbara Minto, é uma técnica de comunicação. Ela não diz nada sobre se o raciocínio por baixo era sólido. Boa comunicação de uma análise ruim continua sendo uma análise ruim.

É uma habilidade, não um traço de personalidade. Vem com a prática.

Depois de cada conversa importante com um cliente, escreva o problema como você o entende, a sua decomposição, a sua hipótese e a evidência que a testaria. Faça isso antes de olhar qualquer dado. Escrever força uma clareza que pensar de cabeça não força.

Pratique a síntese, não só a análise. Pegar uma pilha de evidências e produzir uma recomendação defensável é a metade mais difícil. A maioria dos consultores juniores é razoável em análise e pouco desenvolvida em síntese. É nessa lacuna que está a próxima promoção, e ela é boa parte do que os consultores realmente fazem quando se tiram os jargões.

O que é pensamento estruturado na consultoria?

É dividir um problema complexo e ambíguo em partes, trabalhar cada parte em ordem e combinar as conclusões em uma recomendação clara. Torna os problemas difíceis tratáveis e deixa o raciocínio visível, de modo que o cliente pode acompanhá-lo e questioná-lo em vez de aceitar uma conclusão por fé.

As principais ferramentas são a pergunta de enquadramento, as árvores de questões, o MECE e a análise orientada por hipóteses. Nenhuma delas substitui o julgamento.

O que significa MECE e como ele é usado?

Mutually Exclusive, Collectively Exhaustive: mutuamente exclusivo, coletivamente exaustivo. As partes de uma decomposição não devem se sobrepor e, juntas, devem cobrir o problema inteiro.

Teste de sobreposição: um item poderia estar em dois ramos? Teste de lacunas: se todos os ramos fossem respondidos, a pergunta central seria respondida? Aplique o método ao montar a árvore de questões. Aplicá-lo a uma análise pronta costuma ser tarde demais.

Como funciona a análise orientada por hipóteses?

Você enuncia cedo a resposta mais provável, lista as evidências que a confirmariam ou refutariam e depois vai testá-la. É mais rápido do que reunir tudo primeiro, porque indica onde olhar.

O risco é o viés de confirmação. Procure primeiro a evidência que poderia provar que você está errado.

Como enquadrar corretamente um problema de consultoria?

Pergunte que decisão precisa ser tomada e que informação a mudaria. Depois teste a formulação do problema feita pelo cliente antes de aceitá-la.

Um cliente que pergunta “qual módulo SAP devemos implementar primeiro?” pode estar, na verdade, decidindo “este é o momento certo para começar um programa SAP?”. Responder à pergunta declarada sem testar o enquadramento dá uma análise tecnicamente correta e comercialmente errada.

Qual é a diferença entre análise e síntese na consultoria?

A análise divide um problema ou um conjunto de dados em partes para entendê-las. A síntese combina as conclusões em uma recomendação.

A falha mais comum em entregáveis é ter muita análise e nenhuma síntese: o cliente recebe uma pilha de conclusões e nenhuma resposta à pergunta para a qual contratou você. Escrever a conclusão primeiro força a síntese a acontecer.

Como o pensamento estruturado se aplica a implementações de ERP?

No início do programa, ele impede que as equipes configurem antes de entender o problema real. Uma organização que diz “precisamos de SAP” pode precisar primeiro resolver um problema de processo ou de dados que o SAP só vai tornar mais visível.

No trabalho de fit-gap, uma decomposição MECE dos processos de negócio garante que todos os processos sejam considerados, e não só os levantados nos workshops. Depois de um go-live problemático, enquadrar a decisão (estabilizar, recuperar ou substituir) e testar uma hipótese sobre a causa principal leva a uma recomendação defensável mais depressa do que listar sintomas.