Mantenere la propria metodologia di consulenza in una piattaforma IA

Sì, una società di consulenza può mantenere la propria metodologia, le proprie convenzioni di storyline e i propri template quando adotta una piattaforma di strategia IA, e l'output non deve per forza somigliare a quello di tutti gli altri. Il risultato dipende da una disciplina: separare il metodo in livelli distinti, perché framework, regole di storyline, template visivi, linguaggio della casa, controlli di qualità e gerarchie delle fonti si trasferiscono al software in modi diversi. Configurate i livelli che sono davvero strutturali e lasciate saldamente alle vostre persone i livelli che sono giudizio.

Una piattaforma di strategia IA non deve necessariamente produrre deliverable generici. Scomponendo la metodologia della vostra società in livelli configurabili, come le convenzioni di storyline e la grammatica delle slide, potete automatizzare la struttura mantenendo il giudizio analitico saldamente in mani umane.

La preoccupazione è fondata. In un esperimento sul campo con 758 consulenti di Boston Consulting Group, Dell'Acqua e colleghi hanno rilevato che, sebbene i partecipanti assistiti dall'IA producessero idee di qualità superiore, si osservava «una marcata riduzione della variabilità» di tali idee rispetto a chi non usava l'IA, che gli autori interpretano come una tendenza verso «output più omogeneizzati».^[1] Per una società il cui prodotto è il proprio punto di vista, questo risultato merita attenzione. Se ogni concorrente applica gli stessi modelli agli stessi brief, un uso indifferenziato dell'IA erode esattamente ciò per cui i clienti pagano un premio.

Il rimedio non è evitare gli strumenti, ma trattare la metodologia come qualcosa da specificare, configurare e testare, anziché lasciarla alle impostazioni predefinite del modello. Il resto dell'articolo spiega come farlo e fornisce un protocollo verificabile da eseguire prima di impegnarsi con qualsiasi piattaforma.

La metodologia di una società sembra un tutt'uno indivisibile, ma in realtà è composta da diversi livelli sovrapposti, che non si trasferiscono al software allo stesso modo. Metterli per iscritto separatamente è il primo passo, perché trasforma una vaga ansia di perdere «il nostro modo di lavorare» in un elenco concreto di regole da configurare, testare e approvare. Sei livelli coprono la maggior parte delle pratiche di consulenza:

• (a) Framework e approccio analitico: i modelli proprietari, le sequenze diagnostiche e le ipotesi che strutturano il modo in cui affrontate un problema, e che spesso sono proprio ciò che i clienti acquistano.
• (b) Convenzioni di storyline: le regole che governano come un'argomentazione viene costruita e raccontata, come il pyramid principle, la comunicazione che parte dalla risposta, i titoli d'azione e un'idea per slide.
• (c) Template visivi e grammatica delle slide: layout master, colori e tipografia, convenzioni per i grafici, elementi fissi di pagina e collocazione di fonti e note.
• (d) Terminologia e linguaggio della casa: le parole che usate ed evitate, come denominate fasi e ruoli, e il tono che rende un documento riconoscibilmente vostro.
• (e) Controlli di qualità e passaggi di approvazione: chi rivede che cosa, secondo quali criteri, prima che qualcosa arrivi a un cliente, e chi è responsabile a ogni controllo.
• (f) Gerarchia delle fonti: di quali evidenze la società si fida, in quale ordine di preferenza, e che cosa non può mai essere citato come base di una raccomandazione.

I livelli differiscono per quanto possono essere delegati. Convenzioni di storyline, template, terminologia e gerarchia delle fonti sono in gran parte regole esplicite, ed è proprio questo che il software sa seguire bene. Framework e controlli di qualità contengono un giudizio tacito, ed è lì che resta il contributo umano. Tenere presente questa distinzione previene entrambi i modi di fallire: affidare tutto allo strumento e perdere la propria distintività, oppure rifiutare lo strumento e perdere l'efficienza che i concorrenti stanno guadagnando.

Gran parte di ciò che rende un deliverable riconoscibilmente vostro risiede nei livelli (b), (c), (d) e (f), e sono esattamente i livelli che una piattaforma ben progettata può essere configurata per seguire. Le convenzioni di storyline sono il caso più evidente. Il pyramid principle di Barbara Minto, sviluppato durante gli anni in McKinsey, sostiene che una scrittura chiara ha una struttura piramidale: un pensiero guida al vertice, sostenuto da idee raggruppate in un ordine logico, con ogni livello che riassume quello sottostante.^[2] Regole di questo tipo sono esplicite e verificabili, il che le rende adatte a essere codificate in una piattaforma: ogni titolo di slide è una conclusione in forma di frase completa, un'idea per slide, la risposta enunciata prima delle evidenze.

• Regole di storyline: struttura piramidale, flusso che parte dalla risposta, titoli d'azione e il vincolo di un'idea per slide possono essere impostati come regole di generazione, anziché lasciati al gusto del modello.
• Template visivi: i vostri layout master, la palette di colori, la tipografia e le convenzioni dei grafici possono essere applicati alla presentazione generata, così che l'output si apra nel vostro stile della casa anziché in uno generico.
• Terminologia: il vocabolario della casa, le formulazioni preferite e le parole vietate possono essere specificati, così che il documento parli con la vostra voce.
• Gerarchia delle fonti: potete definire su quali fonti la piattaforma può basarsi e in quale ordine di autorevolezza, così che la base di evidenze rifletta i vostri standard anziché le impostazioni predefinite del web aperto.

Una configurazione di questo tipo non è cosmetica. Quando le regole strutturali sono fissate da voi, l'output di base della piattaforma parte dalle vostre convenzioni invece di scivolare verso uno stile della casa che non appartiene a nessuno. L'implicazione pratica per gli acquisti è semplice: chiedete a ogni fornitore di dimostrare, sul vostro template e sulle vostre regole di storyline, come funziona la sua configurazione, e considerate un segnale d'allarme qualsiasi risposta che equivalga a «il modello sa come sono fatte le presentazioni di consulenza».

Alcuni livelli non dovrebbero essere ceduti, per quanto bene funzioni la piattaforma. I vostri framework proprietari e il vostro approccio analitico sono il cuore di ciò che i clienti acquistano, e incorporano un giudizio che solo le vostre persone più esperte possono esercitare: quale ipotesi conta, quale tensione nei dati è la vera storia, quando il framework va messo da parte. Una piattaforma può eseguire un framework che specificate voi; non può generare il giudizio sul fatto che quel framework si adatti alla situazione di questo cliente.

• Selezione e adattamento del framework: scegliere l'approccio analitico per questo incarico e adattarlo dove la realtà del cliente non corrisponde al modello.
• Interpretazione dei risultati: decidere che cosa significano le evidenze per questo cliente e quali compromessi la raccomandazione dovrebbe soppesare.
• Controlli di qualità e approvazione: i passaggi di revisione del livello (e) esistono proprio perché una persona senior risponde di ciò che esce dalla società, e questa responsabilità non può essere delegata al software.
• La relazione con il cliente: le conversazioni, la fiducia e il contesto che determinano quali consigli verranno davvero ascoltati, a nessuno dei quali una piattaforma partecipa.

Un modo utile di inquadrare la divisione del lavoro: il software struttura l'argomentazione e raccoglie le evidenze, mentre il team di consulenza è titolare del giudizio, della relazione e dell'approvazione finale. Se la proposta di un fornitore lascia intendere che la piattaforma sostituisce la revisione del partner, significa che non ha capito a che cosa serve un controllo di qualità; vale la pena stabilire esplicitamente quanta revisione umana serve a una presentazione strategica IA prima che qualcosa arrivi a un cliente. Il test della prossima sezione offre un modo per verificare dove finiscono davvero le capacità di una piattaforma, prima di impegnarvi.

Le affermazioni sulla configurabilità vanno testate, non credute. Il protocollo che segue si inserisce in un approccio pilota più ampio: se state valutando una piattaforma nel suo complesso, completa il metodo del back-test descritto altrove, che valuta l'output della piattaforma rispetto alla presentazione effettivamente vista dal consiglio. Il test di trasferimento della metodologia restringe il campo a una sola domanda: l'output si legge ancora come lavoro della vostra società? Si svolge in sei passaggi.

1. Redigete l'inventario. Elencate il vostro metodo secondo i sei livelli della sezione precedente e date a ciascun livello almeno una regola concreta e verificabile. «Usare un linguaggio chiaro» non è verificabile; «ogni titolo di slide è una conclusione in forma di frase completa che enuncia il messaggio chiave» lo è.
2. Scegliete un incarico passato concluso di cui conoscete l'esito. Sceglietene uno in cui il deliverable è stato accolto bene, così da avere un termine di confronto autentico, e in cui la riservatezza consente il riutilizzo interno dei documenti.
3. Configurate la piattaforma con l'inventario e sottoponetele il brief e i documenti originali. Impostate le regole di storyline, i template, la terminologia e la gerarchia delle fonti esattamente come li avete scritti, poi lasciate che la piattaforma produca il proprio output dallo stesso punto di partenza del vostro team.
4. Valutate ogni regola. Per ciascuna regola dell'inventario, registrate se è stata mantenuta, parzialmente mantenuta o persa. Siate severi: una regola che compare nella maggior parte delle slide ma non in tutte è parzialmente mantenuta, non mantenuta.
5. Fate eseguire una revisione alla cieca da un partner. Un partner che non ha condotto il test legge l'output della piattaforma accanto al deliverable originale e risponde a una sola domanda: un cliente lo riconoscerebbe come nostro lavoro? Registrate la risposta e le motivazioni, con le parole del partner.
6. Decidete. Le regole perse nel livello (a), i framework, o nel livello (e), i controlli di qualità, sono bloccanti: toccano il giudizio e la responsabilità, e una piattaforma che non riesce a rispettarle non è pronta. Le regole perse nel livello (c), i template, o nel livello (d), la terminologia, sono lavoro di configurazione: sono regole esplicite, e il fallimento è un problema di impostazione da correggere e ritestare.

La regola decisionale conta più dei punteggi. Separa i fallimenti che dovrebbero fermare un acquisto da quelli che dovrebbero fermare una riunione di rollout, e fornisce una base documentata per l'una o l'altra decisione. Se vi serve un protocollo più approfondito per esaminare l'output stesso una volta configurata la piattaforma, l'approccio descritto in verificare i fatti di una presentazione strategica generata dall'IA si abbina bene al quarto passaggio.

L'esempio che segue è un'ipotesi illustrativa, non il resoconto di un incarico reale, e le cifre descrivono uno scenario anziché risultati riportati. Immaginate una boutique di 12 persone nota per un framework proprietario di diagnostica dei prezzi: una sequenza in quattro fasi, dalla mappatura dei margini fino alle leve negoziali, con le proprie convenzioni di storyline e una rigida gerarchia delle fonti che privilegia i dati transazionali rispetto alle stime da sondaggio. I partner eseguono il test di trasferimento della metodologia su un incarico concluso prima di impegnarsi con una piattaforma.

Notate che cosa ha cambiato l'esercizio. La regola terminologica persa era una lacuna di configurazione, non un limite della piattaforma, e la correzione ha richiesto un solo nuovo test. La regola del template parzialmente mantenuta ha rivelato che «usare la nostra palette» era troppo vago per essere configurato, il che è di per sé una scoperta sulla documentazione della società. Il controllo di qualità non è mai stato offerto alla piattaforma, perché i partner avevano già deciso che il livello (e) non è negoziabile. La risposta del revisore alla cieca, in questa ipotesi, è stata che l'output sarebbe passato per lavoro della società una volta applicata la correzione terminologica.

Decisity è una piattaforma di consulenza strategica nativa per l'IA costruita proprio per la sfida di configurazione descritta in questo articolo. È configurabile secondo le convenzioni di storyline e la formattazione di una società, così che l'output si legga come lavoro della società anziché della piattaforma, e applica come impostazioni predefinite del metodo il pyramid principle, i titoli d'azione e un'idea per slide. Ogni affermazione, numero e raccomandazione in una presentazione Decisity è riconducibile alla propria fonte, con un audit trail (traccia di audit) completo dalla conclusione fino alle evidenze, e questa tracciabilità delle fonti persiste, così che una decisione possa essere riesaminata in seguito rispetto alle evidenze su cui si basava. I documenti dei clienti non vengono utilizzati per addestrare modelli condivisi, un aspetto importante per qualsiasi società che configuri framework proprietari nella piattaforma.

Per le società di consulenza, la sequenza pratica è quella descritta sopra: redigere l'inventario, eseguire il test di trasferimento della metodologia su un incarico concluso e lasciare che a decidere siano i punteggi, non la conversazione commerciale. Configurata e testata in questo modo, una piattaforma dovrebbe rendere la vostra metodologia più esplicita di quanto fosse prima, e i deliverable inconfondibilmente vostri.

Letture correlate:

• Dichiarare l'uso dell'IA ai clienti: le lettere d'incarico per i consulenti
• Come testare in pilota una piattaforma di strategia AI: il back-test

• Dell'Acqua et al.: Navigating the Jagged Technological Frontier (Harvard Business School Working Paper 24-013, 2023)
• Think Insights: The Pyramid Principle (Barbara Minto)