Tom Godden:
Abbiamo vissuto nel 2023 e nel 2024 un po' di entusiasmo legato all'IA generativa, forse anche un po' di eccesso di aspettativa. Personalmente, penso che qui in AWS siamo molto convinti che col passare del tempo vedremo quasi tutte le applicazioni potenziate dall'IA e dall'IA generativa. Ma con questo scenario in mente, come possiamo aiutare i leader a razionalizzare la loro proposta di business case sull'IA generativa in modo che non la sopravvalutino? In modo da trovare il valore giusto. Come consiglieresti di procedere in questo senso?
Matt Fitzpatrick:
Questo spiega in parte perché solo l'8% ce la sta facendo in questo momento. Credo che l'incertezza riguardo al successo sia un aspetto complicato nel processo di sviluppo del caso aziendale. Quello che intendo dire è che, per esempio, se desideri installare un nuovo sistema software per gestire qualsiasi processo come le spese, adesso creeresti un caso aziendale sapendo esattamente quale flusso di lavoro bisognerà seguire, con una fiducia molto alta nel risultato. In questo caso, creare un caso aziendale è un processo relativamente semplice. Ma immagina che il tuo caso aziendale si basi su 12 fattori diversi che potresti utilizzare nella tua organizzazione...
Tom Godden:
Risolvilo per N, sì.
Matt Fitzpatrick:
Dove cinque di loro potrebbero avere successo e sette potrebbero non funzionare. Penso che in realtà sia necessario cambiare il modo in cui funziona lo sviluppo di business case, facendo sì che somiglino molto di più a un approccio tipico del capitale di rischio. Non penso che questo significhi che solo una su dieci vada a buon fine, ma piuttosto che bisogna essere pronti a sperimentare, provando 10, 12, 14 cose diverse. Con il tempo, nel primo ciclo otterrai cinque progetti che funzionano, e nel ciclo successivo dieci che vanno bene. Inoltre, non investirai enormi somme per sviluppare ciascuno di essi.
Per fare un esempio, prendiamo in considerazione la gestione della conoscenza: gli stessi dati che utilizzi per una chiamata di servizio potrebbero essere utili anche per i contact center, per la produzione di documenti sullo svolgimento della chiamata, e così via. Alla fine, ti ritroverai con 5, 6, 7 casi d'uso collegati a quello che hai sviluppato e che ha avuto successo.
Tom Godden:
Ed è bellissimo. E consiglio sempre alle persone di provare prima con quel caso d'uso riassuntivo del documento, ma poi applicarlo in altri ambiti come le risorse umane o la finanza. Sarà necessario fare qualche aggiustamento e addestrare un po' il modello, ma in ogni caso avrai già fatto l'80%-90% del lavoro.
Matt Fitzpatrick:
La difficoltà con i casi aziendali è stata proprio questa. Non stai seguendo un paradigma in cui hai un progetto che richiederà due anni e alla fine sarà un caso unico e monolitico che, una volta completato, è finito. In realtà, stai adottando più di un paradigma del tipo: "Ho bisogno di raccogliere quattro diversi componenti di dati per questo caso d'uso. Ognuno di questi componenti è modulare, posso utilizzarli per altri quattro casi d'uso". Quindi in realtà lo sviluppo del caso aziendale diventa: "Ha senso investire qui, in modo da costruire funzionalità che possano giustificare l'avvio del progetto, perché saranno utili ripetutamente per altre applicazioni?" E col tempo, su una base di tre o cinque anni, il ritorno sull’investimento sarà moltiplicato. Potrebbe però non avvenire subito con il primo caso.
Tom Godden:
Quindi Matt, facciamo finta che io sia un CIO, essendo stato CIO in passato, quindi non è difficile immaginarselo. E supponiamo che mi trovi in una situazione in cui voglio qualcosa di veramente unico, personalizzato per le mie esigenze, ma voglio anche che sia poco costoso, giusto? Non è sempre questo il paradigma? Come si pone McKinsey, come ti comporti quando si tratta di consigliare alle persone di costruire internamente piuttosto che acquistare una soluzione? Quando la costruisci tu, ha la possibilità di personalizzarla. Ma costa molto di più. Quando acquisti, teoricamente spendi di meno, ma ottieni una personalizzazione minore. In qualità di CIO, mi trovo proprio bloccato nel mezzo. Ho bisogno di aiuto. Quale consiglio daresti?
Matt Fitzpatrick:
Sì, sai, sono dell'opinione che in realtà la definizione di "costruire versus acquistare" sia diventata molto distorta nel modo in cui la consideriamo nel settore tecnologico. Ti spiego cosa intendo. 10 anni fa, la definizione di "costruire versus acquistare" significava prendere un prodotto già pronto, che funzionava e che aveva un determinato costo. "Costruire" significava che avrei dovuto mettere in piedi un computer mainframe, sviluppare tutto il mio codice in gran parte da zero in un contesto di 15 anni fa.
Tom Godden:
Costruisci tutto allora.
Matt Fitzpatrick:
Stai costruendo qualcosa da zero e il tuo investimento sarà significativo.
Tom Godden:
Apprezziamo che tu lo dica perché è un po' la strategia di AWS. Aiuta a sostenere quel carico non differenziato.
Matt Fitzpatrick:
Se guardo alla situazione in modo più ampio, senza riferirmi a un singolo fornitore di tecnologia, oggi, "costruire" significa avviare un'istanza cloud. Uso vari componenti modulari. Estraggo il codice GitHub, repository di codice con informazioni. Scelgo sei o sette diversi componenti pronti all'uso che mi consentono di sostenere qualcosa di veramente utile e personalizzato per la mia organizzazione a un costo inferiore rispetto a 10 anni fa.
Tre anni fa, ad esempio, lavoravo con un player di asset che stava valutando se acquistare una piattaforma preconfezionata. Avevano bisogno di ricreare il loro sistema di gestione del credito e la discussione era: "Compro una piattaforma di credito già pronta o ne costruisco una da zero?" E no, non si trattava di una compagnia tecnologica. 10 anni fa l'idea di costruire una piattaforma di credito sarebbe sembrata assolutamente folle.
Tom Godden:
I campanelli d'allarme stanno suonando.
Matt Fitzpatrick:
Ma quando l’hanno esaminata, hanno capito che, per acquistarla, avrebbero dovuto fare un investimento significativo per personalizzare lo schema dei dati in modo che fosse compatibile alla piattaforma di credito standard. Inoltre, avrebbero avuto bisogno di schermate che sembrassero... Avevano un sistema interno che stavano cercando di sostituire con questo, ma ci sarebbe voluto un ingente investimento per adattare il sistema preconfezionato a ciò che desideravano. Avrebbero dovuto investire molto anche per mappare i dati su di esso. E così, quando hanno finito...
Tom Godden:
Cos’è successo?
Matt Fitzpatrick:
Fondamentalmente stavano costruendo un nuovo sistema su una piattaforma preesistente. L’altra opzione che avevano era quella di utilizzare tutti gli strumenti moderni disponibili, come quelli per la gestione dei dati, l'infrastruttura cloud e simili, e creare un sistema. E, incredibilmente, questa soluzione è risultata non più costosa rispetto a quella iniziale.
E stiamo vedendo che questo accade sempre più spesso. Penso che l'IA generativa accelererà ulteriormente questo processo, perché una delle cose che mi entusiasma di più del suo ecosistema è l'interoperabilità di tutte le varie applicazioni. Nessuno sta costruendo soluzioni con l’intento di dire: "Puoi usare solo il nostro sistema". Tutti vogliono che si possa partecipare al meglio della categoria. E così ogni volta che esce una nuova tecnologia, potrai integrarla. La domanda che si pone, quindi, è: se oggi crei una nuova applicazione per la gestione del credito e acquisti una piattaforma, ma poi arriva un nuovo strumento interessante di IA generativa, non potrai più usarlo? In realtà, accumuleresti più debito tecnologico utilizzando la piattaforma di credito preconfezionata ma obsoleta di dieci anni, di quanto faresti se costruissi un moderno stack interoperabile e sempre aggiornato, che ti permetta di integrare tutti i componenti più avanzati.
Devo dire che il numero di aziende che sono a proprio agio nel costruire soluzioni è molto più alto rispetto a cinque anni fa. E tutto ciò è reso possibile dagli investimenti in cloud e infrastrutture, che consentono di farlo in modo molto più rapido.
Tom Godden:
Quindi Matt, hai fatto molte trasformazioni, hai guidato numerosi progetti e hai accumulato molta esperienza. McKinsey discute spesso di come ristrutturare le organizzazioni per renderle capaci di adattarsi. Quali modelli vedi come efficaci per gestire l'aspetto culturale e facilitare il successo mentre ci immergiamo nell'era dell’IA generativa?
Matt Fitzpatrick:
Penso che ci siano un paio di aspetti fondamentali in questo. Uno è essere molto chiari su quali casi d'uso sono effettivamente importanti e possono muovere l'ago della bilancia. Ripeto, se si considera una situazione di 10 anni fa, in cui la propria organizzazione tecnologica non dialogava nemmeno con quella aziendale, c'erano tutti i presupposti per un fallimento. È necessario avere una visione chiara: qual è il mio obiettivo? Quali sono i 10 casi d'uso che proverò a sperimentare? In che modo i miei team tecnici e aziendali lavoreranno insieme per testare e apprendere? Questo intero processo è una nuova abilità. Credo che le competenze che oggi suscitano maggior interesse in questi giorni siano quelle che potremmo definire competenze di "traduzione", ovvero persone che hanno una certa conoscenza digitale ma capiscono anche il business. Ho lavorato con diversi clienti immobiliari, ad esempio, e qualcuno che capisce sia la tecnologia che il settore immobiliare è molto più prezioso di qualcuno che capisce solo una delle due realtà.
Penso che sia necessario avere un legame forte tra l'organizzazione tecnologica e i team aziendali, affinché ciò che viene costruito sia funzionale e risponda alle esigenze degli utenti aziendali. Quindi penso che le competenze di traduzione diventino davvero importanti.
Inoltre, credo sia importante riflettere molto sulla necessità di riqualificazione, o almeno sull'aggiornamento delle competenze tecniche della propria organizzazione ingegneristica. Ad esempio, se hai un'organizzazione ingegneristica che non sa usare Python o anche strumenti più recenti come Rust, sarà più difficile per te sfruttare molti dei moderni strumenti di IA generativa. Quindi ciò potrebbe portare alla necessità di un riaddestramento e di una riqualificazione, a nuove assunzioni, ma sarà necessario potenziare l'organizzazione ingegneristica tradizionale.