Pensiero strutturato: il vero vantaggio del consulente

Il pensiero strutturato è il modo in cui un consulente passa da un problema del cliente vago e confuso a una raccomandazione che la sala può seguire e contestare. Si inquadra la decisione, si scompone il problema in parti che non si sovrappongono, si mette alla prova per prima la risposta più probabile e poi si riuniscono i risultati in un'unica raccomandazione chiara.

Questo articolo è per i consulenti e gli analisti che vogliono un modo ripetibile per farlo sotto pressione. Descrive i quattro strumenti su cui mi appoggio, una scheda di una pagina da usare nel Suo prossimo incarico e ciò che l'AI ha cambiato in questa competenza.

Ho visto persone bloccarsi nelle riunioni con il cliente. Non perché non avessero idee. Perché non sapevano da dove cominciare.

La scena è familiare. Un problema complesso, una sala piena di persone senior, un perimetro vago e l'aspettativa di chiarezza. La reazione non strutturata è cominciare a parlare sperando che la risposta emerga. A volte succede. Più spesso si gira in tondo per venti minuti e nessuno esce soddisfatto.

È la pratica di scomporre un problema ambiguo nelle sue parti, affrontare ogni parte in ordine e riunire i risultati in una raccomandazione.

Non significa compilare un modello e chiamarlo analisi. Non significa forzare un framework su un problema a cui non si adatta. Un consulente che applica una matrice 2x2 a ogni situazione sta riconoscendo schemi, non sta pensando.

Quello che si costruisce è un insieme di capacità:

1. Individuare il problema reale, che spesso è diverso da quello presentato
2. Scomporlo in parti analizzabili separatamente
3. Sapere quali informazioni contano e quali no
4. Costruire un'argomentazione coerente a partire da ciò che si trova
5. Esprimerla con chiarezza quando in sala c'è tensione

I framework sono un'impalcatura mentre queste capacità si sviluppano. Se vuole la cassetta degli attrezzi più ampia, ne tratto i più comuni in framework di consulenza semplici, spiegati.

La domanda di inquadramento

Prima di qualsiasi framework, si pone una domanda. Quale decisione va presa, e quali informazioni la cambierebbero?

Fa di più per la qualità dell'analisi di qualunque strumento strutturale. Costringe a chiarire quale sia il risultato atteso e impedisce di fare un lavoro accurato su una domanda a cui nessuno doveva rispondere. HBR sosteneva la stessa tesi anni fa in Are You Solving the Right Problem?: la maggior parte dello sforzo sprecato nasce da un problema definito male.

In un contesto SAP, «quale modello di deployment si adatta a questa organizzazione» è una decisione. «Che cos'è S/4HANA» è una descrizione. La prima richiede analisi. La seconda richiede documentazione. Sapere quale delle due si sta facendo decide come si spende la settimana.

MECE

MECE sta per Mutually Exclusive, Collectively Exhaustive, cioè mutuamente esclusivo e collettivamente esaustivo. Quando si scompone un problema in parti, ogni parte deve essere distinta (nessuna sovrapposizione) e insieme devono coprire l'intero problema (nessun vuoto).

Le categorie sovrapposte contano due volte. I vuoti fanno perdere elementi. La maggior parte dei consulenti conosce la sigla. Pochi la applicano con rigore.

Due verifiche la tengono onesta. Primo: un elemento potrebbe stare contemporaneamente in due rami? Allora i rami si sovrappongono. Secondo: se si rispondesse a ogni ramo, si risponderebbe anche alla domanda centrale? Se no, c'è un vuoto. Un MECE perfetto è raro. Conta porsi queste due domande ogni volta.

Alberi dei problemi (issue tree)

Un albero dei problemi pone la domanda centrale alla radice e le sottodomande sui rami. Ogni ramo può essere analizzato da solo.

Si prenda «Perché questo go-live di SAP ha superato il budget pianificato del 40%?» La prima suddivisione potrebbe essere modifiche di perimetro, costi delle risorse, proroghe dei tempi e interventi correttivi non pianificati. Le modifiche di perimetro si dividono poi in richieste di modifica formali, aggiunte informali e lacune scoperte tardi. Ogni foglia si può misurare.

Gli alberi dei problemi si ripagano all'inizio di un incarico, prima di aver svolto qualsiasi analisi. Impediscono di passare tre settimane su un ramo lasciandone un altro intatto.

Analisi guidata da ipotesi

Invece di raccogliere tutti i dati e poi concludere, si parte dalla risposta più probabile e la si mette alla prova. Le società di strategia hanno costruito la loro reputazione su questo approccio.

Con poco tempo e un problema complesso, un'analisi esaustiva non è possibile. Una buona ipotesi dice che cosa guardare per primo. Se regge, si ha la risposta. Se cade, le prove che l'hanno smontata di solito indicano una direzione utile.

È anche l'approccio usato più spesso in modo scorretto. I consulenti formulano un'ipotesi e poi cercano solo le prove che la confermano. Ci si chieda quali prove dimostrerebbero che si ha torto, e si vada a cercare prima quelle.

È la sequenza che consegnerei a un nuovo consulente prima della sua prima diagnosi. La si compila prima di aprire un solo foglio di calcolo.

1. 01InquadrareLa decisione, in una frase
2. 02ScomporreDa tre a cinque domande MECE
3. 03Formulare ipotesiUna riga per ramo
4. 04ConfutareLe prove che dimostrerebbero che si ha torto
5. 05VerificareRisultati per ramo, con le fonti
6. 06SintetizzarePrima la raccomandazione, poi le argomentazioni
7. 07Mettere sotto stressObiezioni affrontate prima che le sollevi la sala

Una raccomandazione che regge davanti allo steering committee

Passo	Domanda a cui rispondere	Risultato	Chi lo approva
1. Inquadrare	Quale decisione deve prendere il cliente, ed entro quando?	Una frase	Lo sponsor del cliente
2. Scomporre	Quali tre-cinque domande, a cui si risponde insieme, chiudono quella decisione?	Albero dei problemi di primo livello, verificato con il criterio MECE	Il responsabile dell'incarico
3. Formulare ipotesi	Che cosa penso oggi che sia la risposta, e perché?	Un'ipotesi in una riga per ramo	Il responsabile dell'incarico
4. Confutare	Quali prove dimostrerebbero che ciascuna ipotesi è sbagliata?	Elenco delle richieste di dati, in ordine di priorità	I responsabili dei dati del cliente si impegnano a fornirli
5. Verificare	Che cosa dicono le prove?	Risultati per ramo, con le fonti	I responsabili dei rami nel team
6. Sintetizzare	Quindi, che cosa dovrebbe fare il cliente?	Prima la raccomandazione, poi i punti a supporto	Il responsabile dell'incarico
7. Mettere sotto stress	Chi in sala non sarà d'accordo, e su che cosa?	Obiezioni e risposte, preparate	Un collega che non ha lavorato sull'incarico

Il passo 7 è quello che le persone saltano. È anche quello che decide se la raccomandazione sopravvive allo steering committee.

Un cliente SAP, un grande gruppo manifatturiero, gestiva un panorama ECC molto personalizzato. Il responsabile IT lo disse senza giri di parole: «Dobbiamo ridurre i costi operativi, ma non possiamo permetterci di rompere nulla.»

L'istinto è mettersi a elencare idee di risparmio. Il risultato è un lungo elenco, molte persone nervose e nessuna priorità.

Abbiamo organizzato l'analisi dei costi in tre rami: manutenzione applicativa, infrastruttura e licenze. Poi abbiamo aggiunto l'analisi del codice custom. Quante modifiche erano davvero in uso? Più della metà non lo era. Interfacce ridondanti, report custom inutilizzati, workflow sovrapposti.

Strutturare l'analisi in questo modo ci ha permesso di indicare risparmi che sembravano sicuri, come archiviare gli oggetti custom inutilizzati e consolidare gli ambienti di sviluppo. La chiarezza ha ridotto l'attrito politico e ha creato fiducia. Senza l'albero, sarebbe stato un elenco di tagli che nessuno voleva firmare.

Lo stesso metodo funziona con incarichi più vaghi. Un fornitore di software enterprise ci chiese una volta «una strategia di lancio regionale» per il mid-market saudita. Abbiamo diviso il lavoro in domanda di mercato, posizione competitiva e prontezza dei partner. Sotto la prontezza dei partner abbiamo scoperto che la loro rete di rivenditori aveva poca esperienza con SAP S/4HANA Cloud. Quell'ostacolo avrebbe bloccato l'esecuzione per quanto allettante apparisse il mercato, e la struttura lo ha fatto emergere prima che spendessero il budget della campagna.

I framework non sono cambiati. Sono cambiate altre due cose.

La bozza ormai costa poco. Joule, ChatGPT e Claude producono un albero dei problemi o un albero delle ipotesi in pochi secondi. I consulenti junior che prima passavano una serata su una prima bozza ora la generano in mezzo minuto e dedicano la serata a ciò che il modello non sa fare: verificare se la struttura si adatta al problema, scoprire che cosa gli è sfuggito e mettere in discussione le assunzioni contenute nel prompt.

Il valore del giudizio è cresciuto. Quando tutti possono generare una scomposizione MECE, la domanda non è più «hai scomposto il problema?». Diventa «ti sei accorto che il problema dichiarato dal cliente è un altro, e hai individuato l'assunzione che il modello ha accettato per impostazione predefinita?». I consulenti che hanno costruito il giudizio su incarichi reali hanno oggi un vantaggio più ampio rispetto al 2024.

Quindi la competenza si è spostata. Non è più «sai costruire un albero dei problemi?». È «sai capire quando l'albero abbozzato dall'AI è sbagliato, e correggerlo in una sala del cliente?».

Se sta valutando dove la porta tutto questo nella Sua carriera, i percorsi di carriera di SAPopedia mappano i percorsi della consulenza e il pacchetto carriera di ERPCV aiuta a mostrare in un CV questo tipo di giudizio, anziché limitarsi a elencare framework.

Partire da una soluzione. Il cliente o il consulente ha una risposta in mente prima che il problema sia inquadrato. L'analisi diventa una conferma.

Troppa struttura. Alcuni problemi semplici meritano una risposta diretta, non una scomposizione MECE. Sapere quando non usare la struttura conta quanto sapere come usarla.

Scomporre alla profondità sbagliata. Gli alberi che scendono troppo in profondità troppo presto producono paralisi. Quelli che restano in superficie producono raccomandazioni su cui nessuno può agire. Si adatti la profondità alla decisione e al tempo disponibile.

Analisi senza sintesi. Un albero rigoroso che finisce in uno scarico di dati. La struttura aiuta a pensare. Il giudizio produce la raccomandazione.

Confondere la struttura della comunicazione con la struttura del pensiero. Presentare partendo dalla conclusione, come nel Principio della piramide di Barbara Minto, è una tecnica di comunicazione. Non dice nulla sulla solidità del ragionamento che sta sotto. Comunicare bene un'analisi sbagliata resta un'analisi sbagliata.

È una competenza, non un tratto innato. Si acquisisce con la pratica.

Dopo ogni conversazione importante con un cliente, scriva il problema come lo ha capito, la scomposizione, l'ipotesi e le prove che la metterebbero alla prova. Lo faccia prima di guardare qualsiasi dato. Scrivere impone una chiarezza che il pensiero tenuto in testa non dà.

Eserciti la sintesi, non solo l'analisi. Prendere un mucchio di prove e ricavarne un'unica raccomandazione difendibile è la metà più difficile. La maggior parte dei consulenti junior se la cava con l'analisi ed è meno sviluppata nella sintesi. È in quel divario che sta la prossima promozione, ed è gran parte di ciò che i consulenti fanno davvero una volta tolti i paroloni.

Che cos'è il pensiero strutturato nella consulenza?

È la scomposizione di un problema complesso e ambiguo in parti, l'esame di ciascuna in ordine e la riunione dei risultati in una raccomandazione chiara. Rende trattabili i problemi difficili e rende visibile il ragionamento, così il cliente può seguirlo e contestarlo invece di accettare una conclusione sulla fiducia.

Gli strumenti principali sono la domanda di inquadramento, gli alberi dei problemi, il MECE e l'analisi guidata da ipotesi. Nessuno di essi sostituisce il giudizio.

Che cosa significa MECE e come si usa?

Mutually Exclusive, Collectively Exhaustive, ovvero mutuamente esclusivo e collettivamente esaustivo. Le parti di una scomposizione non devono sovrapporsi e, insieme, devono coprire l'intero problema.

Per verificare le sovrapposizioni: un elemento potrebbe stare in due rami? Per verificare i vuoti: se si rispondesse a ogni ramo, si risponderebbe alla domanda centrale? Lo si applica quando si costruisce l'albero dei problemi. Applicarlo a un'analisi già finita di solito è troppo tardi.

Come funziona l'analisi guidata da ipotesi?

Si enuncia presto la risposta più probabile, si elencano le prove che la confermerebbero o la smentirebbero, poi si va a verificarla. È più rapida che raccogliere tutto prima, perché indica dove guardare.

Il rischio è il bias di conferma. Si cerchino per prime le prove che potrebbero dimostrare che si ha torto.

Come si inquadra correttamente un problema di consulenza?

Ci si chiede quale decisione debba essere presa e quali informazioni la cambierebbero. Poi si mette alla prova l'enunciato del problema del cliente prima di accettarlo.

Un cliente che chiede «quale modulo SAP dovremmo implementare per primo?» potrebbe in realtà stare decidendo «è il momento giusto per avviare un programma SAP?». Rispondere alla domanda dichiarata senza verificare l'inquadramento produce un'analisi tecnicamente corretta e commercialmente sbagliata.

Qual è la differenza tra analisi e sintesi nella consulenza?

L'analisi scompone un problema o un insieme di dati in parti per comprenderle. La sintesi riunisce i risultati in una raccomandazione.

Il difetto più comune nei deliverable è molta analisi e nessuna sintesi: il cliente riceve una pila di risultati e nessuna risposta alla domanda per cui ha ingaggiato il consulente. Scrivere prima la conclusione costringe la sintesi a prendere forma.

Come si applica il pensiero strutturato alle implementazioni ERP?

All'avvio del programma impedisce ai team di configurare prima di aver capito il problema reale. Un'organizzazione che dice «ci serve SAP» può dover prima risolvere un problema di processo o di dati che SAP renderà soltanto più visibile.

Nel lavoro di fit-gap, una scomposizione MECE dei processi aziendali garantisce che ogni processo sia considerato, non solo quelli emersi nei workshop. Dopo un go-live problematico, inquadrare la decisione (stabilizzare, recuperare o sostituire) e verificare un'ipotesi sulla causa principale porta a una raccomandazione difendibile più in fretta che elencare i sintomi.