Perché le trasformazioni digitali della supply chain falliscono (Eric Kimberling) - Ep 181

00:00:00 Eric Kimberling e introduzione di Third Stage
00:04:31 Focus sulle persone piuttosto che sulla tecnologia nei progetti
00:06:14 Inquadrare correttamente le trasformazioni digitali
00:08:08 Superare l’incrementalismo nelle trasformazioni
00:10:53 I pregiudizi dei vendor rischiano di fuorviare gli sforzi
00:12:40 Sfide nelle migrazioni forzate verso il cloud
00:14:46 Basso valore nell’aggiornamento dei sistemi o dei registri
00:19:26 Sensibilità dei sistemi e impatti delle trasformazioni
00:21:38 Vulnerabilità delle grandi aziende nella trasformazione
00:23:39 Le problematiche di leadership aumentano l’avversione al rischio
00:26:22 Mancanza di una prospettiva strategica nelle trasformazioni
00:29:42 Importanza della mechanical sympathy nella leadership
00:32:42 La latenza dei dati ostacola il calcolo distribuito
00:35:42 I costi elevati dell’elaborazione dei dati a terabyte
00:38:38 Analisi del rischio nella trasformazione tecnologica
00:41:43 Strategie visionarie per le trasformazioni digitali
00:44:25 Equilibrare i budget dei progetti con i rendimenti
00:47:42 Aspettative di costi realistici nelle trasformazioni
00:50:58 L’eccesso di funzionalità software ostacola la produttività
00:53:29 Focus sui processi aziendali invece della tecnologia
00:56:39 Gestione interna delle trasformazioni tecnologiche
00:59:45 Burocrazia nell’esecuzione della pianificazione strategica
01:02:48 La governance previene il caos nelle supply chain
01:06:27 Una revisione completa per trasformazioni ambiziose
01:09:34 Ottimizzare il capex per il valore della supply chain
01:12:20 Inefficienze nelle trasformazioni attuali
01:15:28 L’utilizzo dei dati da parte dei vendor per un vantaggio competitivo
01:18:11 Incentivi finanziari che influenzano la produttività
01:21:13 Inseguire promettenti sviluppi della tecnologia software
01:23:19 Evitare fallimenti costosi riconoscendo i costi sommersi

Sommario

Nel loro dibattito sulle trasformazioni digitali della supply chain, Eric Kimberling e Joannes Vermorel evidenziano i frequenti fallimenti dovuti a pressioni dettate dai vendor e priorità disallineate. Kimberling, alla guida della Third Stage Consulting Group, sostiene strategie non legate alla tecnologia, enfatizzando le esigenze aziendali oltre i semplici aggiornamenti software. Avverte contro decisioni affrettate spinte dai vendor che spesso non riescono a fornire risultati trasformativi. Vermorel sottolinea l’importanza di sfruttare i sistemi esistenti con add-on innovativi anziché ricorrere a sostituzioni dirompenti. Entrambi i leader insistono sull’allineare gli sforzi di trasformazione con obiettivi aziendali tangibili e evidenziano che la gestione del cambiamento è fondamentale per il successo. Essi promuovono un’adozione graduale e consapevole della tecnologia, assicurando che gli obiettivi siano definiti e i rischi siano gestiti.

Sommario Esteso

Quando si esamina il motivo per cui le trasformazioni digitali della supply chain spesso falliscono, è fondamentale considerare le intuizioni condivise dai leader del settore come Eric Kimberling e Joannes Vermorel nel loro recente dialogo, ospitato da Conor Doherty. Entrambi vantano una vasta esperienza nel guidare le aziende attraverso le acque insidiose dei cambiamenti tecnologici, e le loro prospettive rivelano verità cruciali spesso trascurate dalle organizzazioni che intraprendono tali iniziative.

Eric Kimberling, una figura di spicco nel pensiero di leadership tecnologica, guida la Third Stage Consulting Group—una società dedicata a offrire consulenza indipendente e non legata alla tecnologia alle organizzazioni che aspirano a trasformazioni digitali di successo. La sua azienda opera sotto una mission chiara: potenziare i clienti attraverso consigli imparziali che mettono in primo piano le esigenze aziendali rispetto ai semplici aggiornamenti tecnologici. L’approccio di Eric sottolinea la necessità che le trasformazioni si concentrino non semplicemente sulle soluzioni tecnologiche, ma piuttosto su un cambiamento organizzativo olistico che abbracci processi e persone oltre la sola tecnologia.

La conversazione mette rapidamente in evidenza il concetto di “tech agnosticism”, un principio che Kimberling sostiene debba essere al centro di ogni progetto di trasformazione di successo. Egli avverte contro i pregiudizi guidati dai vendor che danno priorità agli aggiornamenti software rispetto alle vere esigenze aziendali, un sentimento che trova eco anche in Vermorel. I vendor spesso spingono per tempi rapidi di aggiornamento—a strategy che può inavvertitamente intrappolare le aziende in decisioni affrettate che producono miglioramenti incrementali, anziché trasformativi. Eric avverte che tali aggiornamenti sotto pressione raramente sono in linea con gli obiettivi organizzativi a lungo termine e spesso diminuiscono il valore che la trasformazione digitale intende offrire.

Joannes Vermorel, fondatore di Lokad, delinea i domini di enterprise software in “sistemi di record,” “sistemi di report,” e “sistemi di intelligence,” sostenendo che le trasformazioni non dovrebbero concentrarsi miopiamente sui sistemi di record che offrono un valore aggiunto minimo. Sia Vermorel che Kimberling riconoscono strategie alternative da aziende come Palantir e Snowflake, che migliorano i sistemi esistenti senza la necessità di una sostituzione dirompente, evidenziando il vantaggio strategico di adattare le infrastrutture attuali con add-on innovativi.

Un tema ricorrente nel loro dialogo emerge, rivelando che le grandi corporazioni sono particolarmente vulnerabili a fallimenti costosi durante le trasformazioni digitali. Kimberling osserva che tali fallimenti spesso derivano da soluzioni complesse accompagnate da una forte avversione al rischio e da una mancanza di responsabilità decisiva, evidenziando una necessità intrinseca di curiosità meccanica—un concetto che esorta i leader aziendali a conoscere intimamente i requisiti digitali della loro impresa. Senza questa curiosità, le aziende vacillano quando esternalizzano eccessivamente, trattando i fornitori come principali attori anziché come subappaltatori del cambiamento.

I leader sottolineano l’importanza di allineare le strategie di trasformazione digitale con obiettivi aziendali tangibili. Presentano la prospettiva inquietante di budget gonfiati dedicati agli upgrade ERP senza un ROI chiaro—o peggio, progetti che trascurano del tutto l’analisi del ROI e dei benefici. La discussione evidenzia la cruciale importanza della gestione del cambiamento—l’elemento essenziale spesso trascurato per il successo della trasformazione. Le trasformazioni che trascurano l’assimilazione culturale e una formazione completa sono destinate a complicazioni, indipendentemente dalla capacità tecnica impiegata.

Nell’identificare i casi di successo, Kimberling e Vermorel delineano l’importanza della chiarezza e della brevità nei documenti di pianificazione. Piuttosto che presentazioni PowerPoint ingombranti, piani testuali concisi favoriscono una comprensione più profonda e facilitano una comunicazione più chiara tra le parti interessate. Esaltano le virtù di trattare gli investimenti tecnologici come spese in conto capitale—valutandoli come asset duraturi anziché semplici spese operative.

Concludendo il dialogo, la coppia ribadisce che, sebbene le trasformazioni trainate dalla tecnologia possano essere catalizzatori potenti per l’evoluzione aziendale, il loro successo dipende da un attento equilibrio tra l’adozione di innovazioni software e la promozione del cambiamento organizzativo. Kimberling consiglia di intraprendere queste trasformazioni con gradualità e consapevolezza, assicurandosi che gli obiettivi siano rigorosamente definiti prima di accelerare le implementazioni. Vermorel concorda, promuovendo impegni incrementali e un approccio “fail fast” che mitiga il rischio pur lasciando spazio all’adattamento.

Attraverso il loro scambio, Kimberling e Vermorel illuminano il percorso per le organizzazioni che contemplano trasformazioni digitali—esortando i leader a considerare più del semplice fascino delle tecnologie di tendenza, concentrandosi invece sull’allineamento di questi progetti con gli obiettivi aziendali complessivi e le aspirazioni.

Trascrizione Completa

Conor Doherty: Bentornati a Lokad. Oggi sono felice di ospitare una conversazione tra Eric Kimberling e Joannes Vermorel. Ora, Eric è il CEO e fondatore di Third Stage Consulting Group, e oggi si unisce a noi per condividere il suo punto di vista unico sul perché così tante trasformazioni digitali falliscono in supply chain. Ora, mentre siete qui, se vi piace ciò che facciamo a Lokad, considerate davvero di iscrivervi a Lokad TV qui su YouTube. Aspetterò.

Va bene, grazie. E seguiteci anche su LinkedIn, e con questo vi presento la conversazione di oggi con Eric Kimberling. Innanzitutto, Eric, ti ringrazio molto per esserti unito a noi, e benvenuto a Lokad.

Eric Kimberling: Grazie per avermi invitato. È un piacere essere qui.

Conor Doherty: Quindi, Eric, prima di addentrarci negli argomenti principali della conversazione, devo dire che sei una voce molto popolare online. Infatti, ti ho scoperto per la prima volta su LinkedIn. Hai un seguito notevole, e sei prolifico anche su YouTube. Ora, abbiamo un pubblico prevalentemente europeo, quindi potrebbe non conoscere bene te. Potresti fornire una breve introduzione per il nostro pubblico che non è in Nord America? Cosa fa Third Stage Consulting Group, come sei arrivato fin qui, ecc.?

Eric Kimberling: Sì, Third Stage Consulting Group è una società di consulenza per la trasformazione digitale con sede negli Stati Uniti. E la chiave del nostro modello di business è che siamo indipendenti e tech agnostic. Quindi aiutiamo i clienti in tutto il ciclo di vita, dalla strategia digitale e valutazione e selezione del software, alla pianificazione dell’implementazione, fino alla gestione effettiva del programma di implementazione e alla gestione del cambiamento.

Abbiamo quasi 100 consulenti. In realtà, abbiamo un piccolo ufficio in Europa con base nel Regno Unito che si occupa della regione EMEA. Quindi hai ragione nel dire che non siamo ancora così diffusi in Europa, ma i nostri obiettivi sono di avere una presenza nella regione EMEA quanto in Nord America. In realtà, ho fondato l’azienda nel 2018 proprio perché sentivo che non c’erano abbastanza consulenti veramente tech agnostic, obiettivi e che rappresentassero realmente gli interessi dei clienti.

Quindi questa è davvero la premessa per cui ho iniziato l’azienda. Era semplicemente per offrire ai clienti un’alternativa al modello tipico di consulenza.

Conor Doherty: Quando parli del modello tipico di consulenza, presumo che il tech agnosticism sia una parte importante di ciò, ma potresti spiegare cosa intendi con questo termine? È una frase bella, ma cosa intendi per tech agnosticism?

Eric Kimberling: Certo, tech atheism, mi piace anche quel termine. È persino migliore. No, quindi tech agnostic significa che non siamo commissionati dai fornitori di software. In altre parole, non guadagniamo quando guadagnano i fornitori. Guadagniamo solo direttamente dai nostri clienti. Ed è una sfumatura davvero importante, perché la maggior parte delle società di consulenza è incentivata direttamente dai fornitori di software per espandere il loro impatto sul mercato o sulla regione il più possibile.

Hanno un gruppo di risorse focalizzato su una sola tecnologia, e il loro obiettivo è far lavorare quei consulenti su progetti incentrati su quella specifica tecnologia. Questo pregiudizio crea una mentalità incentrata sulla tecnologia nella trasformazione, mentre a mio parere, le trasformazioni di maggior successo, siano esse trasformazioni della supply chain o implementazioni ERP, o qualunque cosa possano essere, sono guidate dalle necessità aziendali e dalla definizione di una strategia e di una road map che rispondano a tali esigenze—non partire dalla tecnologia e poi cercare di capire come questa possa adattarsi all’azienda. Può sembrare un dettaglio molto minimo, ma in realtà è decisivo e rappresenta un grande fattore per il successo o il fallimento sul mercato.

Conor Doherty: Bene, grazie, e Joannes, a te la parola tra poco. Eric ha menzionato le dichiarazioni del problema. So che avere una migliore comprensione di una dichiarazione del problema è fondamentalmente la base per qualunque cosa tu voglia realizzare. Quindi, quali sono i tuoi pensieri su quanto ha detto Eric e come si inserisce nella tua visione della trasformazione digitale?

Eric Kimberling: In realtà, la definiamo come abilitazione tecnologica in tutta l’impresa. Non si tratta solo di tecnologia; si potrebbe dire che ancora più importante è l’aspetto operativo e organizzativo, i processi e le persone.

Quando guardiamo a tecnologie specifiche, la maggior parte delle persone parte dal presupposto che sia necessario sostituire la propria tecnologia. Di solito, questa è la dichiarazione del problema: “Dobbiamo sostituire una certa tecnologia.” Quella tecnologia potrebbe essere un sistema di supply chain, potrebbe essere un sistema ERP, potrebbe essere un CRM o un sistema di gestione delle relazioni con i clienti; potrebbe essere un sistema HR, finanziario, e persino ora, con l’IA che è così importante, potrebbe essere IA, potrebbe essere business intelligence.

Quindi ci sono tutti questi diversi tipi di tecnologie tra cui scegliere. A nostro avviso, quando si pensa a trasformazione digitale, si tratta di un termine piuttosto ampio e vago. Comprende molte cose diverse, molte tecnologie differenti, e ciò che è più importante è che, a mio parere, il termine trasformazione digitale è un po’ fuorviante perché fa pensare che si parli di tecnologia. In realtà, questi progetti diventano tipicamente molto più una questione di gestione delle persone e meno di tecnologia.

Conor Doherty: Grazie Eric, e Joannes, a te la parola tra poco. Eric ha menzionato le dichiarazioni del problema. So che avere una migliore comprensione di una dichiarazione del problema è fondamentalmente la base per qualunque cosa tu voglia realizzare. Quindi, quali sono i tuoi pensieri su quanto ha detto Eric e come si inserisce nella tua visione della trasformazione digitale?

Joannes Vermorel: Concordo pienamente sull’importanza del tech agnosticism se si vuole offrire un buon consiglio. È assolutamente fondamentale; altrimenti, il problema verrà letteralmente inquadrato come ciò che espande la presenza di chi ha già un piede nella porta come fornitore. Questo porterebbe, e poi il progetto degenererebbe in una questione di come aggiornare l’ERP di questo fornitore dalla versione N a N+1. Alla fine, è come una ricetta per un investimento massiccio con pochissimo da mostrare.

Gli incentivi non sottovalutano il potere dell’incentivo di inquadrare correttamente la dichiarazione iniziale del problema. Può sembrare pochissimo, ma ciò che ho osservato è che quelle pochissime decisioni che vengono prese tipicamente molto presto nel processo possono poi definire completamente i milioni di dollari che saranno spesi negli anni successivi. Quindi, sono molto d’accordo sul fatto che è assolutamente fondamentale schierarsi dalla parte del business. Cosa vogliamo consegnare, senza ancora chiedersi quale fornitore? E poi c’è la questione secondaria che è, davvero, e concordo pienamente con la tua visione, che la trasformazione digitale riguarda veramente il tipo di azienda in cui diventeremo se potremo fare le cose meglio con quegli strumenti più sofisticati e simili.

A differenza del pensare a una progressione lineare passando dalla versione N alla versione N+1, e questa di solito è una questione molto complicata perché, ad esempio, potresti pensare: “Ok, abbiamo così tante persone che fanno questo, quello e lo scorso”, ma si scopre che forse, se fossimo meglio organizzati, non avremmo nemmeno bisogno di fare quelle cose in primo luogo. Quindi, non ha senso cercare di ottimizzare ciò che fanno, perché la migliore organizzazione non avrebbe nemmeno bisogno di farlo fin dall’inizio. Vedo questo come una sfida per pensare veramente al business. Cosa state realizzando effettivamente?

E poi bisogna avere un buon senso della tecnologia, di ciò che può fare e di ciò che non può fare. Ma direi che è un lontano secondo rispetto all’avere una comprensione molto chiara del business e di ciò che si sta cercando di ottenere. Questa inquadratura mi piace molto, e credo che per me la più grande sfida della maggior parte delle aziende, penso in Europa ma forse anche in una certa misura negli Stati Uniti, in questa trasformazione digitale sia la maledizione dell’incrementalismo. Pensano davvero allo stesso prodotto con qualche campanello e fischietto in più, o vorrebbero avere lo stesso ERP ma con un’interfaccia web invece che con un’interfaccia desktop o altro.

E per me, sì, sarebbe una cosa carina, ma fondamentalmente il ritorno sull’investimento per quei progetti così costosi, voglio dire, non giustifica la spesa. Non si aggiorna un ERP perché ci si è stancati della sua interfaccia brutta. Se funziona, funziona, anche se non è bello da vedere. Se vuoi aggiornare e passare anni a farlo, devi avere qualcosa che renda realmente migliore la tua azienda in seguito, non solo uno strumento dall’aspetto più gradevole, ma che trasformi l’azienda stessa. Questo sarebbe il mio concetto di cosa significhi una trasformazione digitale genuina e correttamente eseguita.

Eric Kimberling: Sì, è un ottimo punto, perché ci sono diverse osservazioni valide in questo discorso. Una riguarda la pianificazione e le decisioni iniziali che vengono prese e come queste definiscono la traiettoria del progetto. È molto vero, e molte organizzazioni, penso, sentono che affretteranno queste decisioni, entreranno nel progetto e poi sistemeranno tutto durante il corso del progetto. Ed è qui che le cose si complicano e manca una direzione chiara.

Ma l’altra cosa a cui alludi è che a volte va bene dire “non aggiorneremo la nostra tecnologia”. E se non ti aggiornassi al sistema più nuovo e sofisticato in circolazione? E se invece ottimizzassi ciò che hai? E se ti concentrassi sul modificare i tuoi processi aziendali per renderli più ottimizzati? E se formassi le persone su come utilizzare meglio il software? E se facessi tutte queste operazioni a basso costo che offrono un valore estremamente elevato e un rischio ridotto per l’organizzazione? Perché non considerarlo come un’opzione?

Ora, i fornitori di software sarebbero fortemente in disaccordo con me. Se fossi un fornitore di software, direi che è un’idea terribile; devi aggiornare tutte le tue tecnologie, devi passare al cloud, ti serve l’AI, ti serve tutta questa roba perché sto cercando di venderti tecnologia. Ma se ti fermi e rimuovi l’emozione e il pregiudizio del fornitore, molte volte le organizzazioni giungono alla conclusione che: “Sai una cosa? Non abbiamo bisogno di affrettarci ad aggiornare al cloud solo perché il nostro fornitore ci dice che abbiamo una scadenza per farlo.”

E penso che sia davvero importante prendere in mano la trasformazione e basarla sulle esigenze del tuo business, sulle tue priorità e sulle tue strategie, non sui fornitori di software.

Conor Doherty: Eric, se posso semplicemente approfondire, e non voglio mettermi in testa le tue parole, ma l’implicazione è che le persone sono forse un po’ fuorviate dai consulenti o dai fornitori e che ciò porta a fallimenti nella trasformazione digitale? In caso contrario, quali ritieni siano alcune delle ragioni più comuni per cui le trasformazioni digitali falliscono?

Eric Kimberling: Sì, è una domanda ottima. Potremmo dedicare l’intera intervista a discutere questa questione. Ma per riassumere, direi sì, i pregiudizi sono sicuramente fattori che contribuiscono al fallimento. Se sono un consulente di software e arrivo con una visione miope secondo cui questa è la tecnologia di cui ho bisogno per integrarmi nella tua organizzazione, hai già creato un disallineamento, perché non metto il tuo business al primo posto, ma la mia tecnologia.

La mia tecnologia ha le best practices; la mia tecnologia ha flussi di lavoro integrati; devi adeguarti al mio software perché il mio software è ottimo. È solo un processo molto dirompente per questo motivo. Quindi, penso che il pregiudizio sia parte del problema; è un grande fattore che contribuisce. Ma quello che ritengo ancora un fattore contribuyente maggiore, che molte persone non riconoscono, è che molti di questi grandi fornitori di software, come se pensi a SAP o Microsoft, stanno essenzialmente costringendo i loro clienti ad aggiornare la tecnologia, dicendo: “Rimuoveremo la manutenzione e il supporto per il tuo vecchio sistema; lo rimuoveremo in questa data, e hai tempo fino a quella data per passare al nuovo sistema, altrimenti interrompiamo il supporto.”

E penso che sia estremamente sconsiderato; non è una definizione di problema focalizzata sul cliente. È essenzialmente prendere un problema del fornitore e trasformarlo nel problema del cliente. Il problema del fornitore è: dobbiamo passare al cloud perché è più redditizio per noi; i nostri investitori lo esigono. Quindi, quel problema diventa il problema del cliente perché ora dicono: “Ehi, so che forse hai implementato una soluzione on-premise, diciamo, due anni fa, ma indovina un po’? Stiamo interrompendo il supporto per quel sistema che hai appena implementato; interromperemo il supporto tra due o tre anni, e hai tempo fino ad allora per passare al nuovo sistema.”

Quindi, questo crea un panico affrettato nelle organizzazioni, ed è il peggiore dei casi quando si cerca di affrontare questa trasformazione, perché porta a molte delle cose che stai menzionando, ovvero che si opta per miglioramenti incrementali. Si spende tutto questo tempo, denaro e rischio solo per ottenere forse dei miglioramenti minori per il business, ed è difficile giustificare il ROI seguendo questo processo.

Conor Doherty: Joannes, so che sei un grande fan dei fornitori e li difendi a spada tratta, ma posso chiederti un commento a riguardo?

Joannes Vermorel: Sì, intendo dire, la mia opinione è che l’industria del software, a proposito, vedo il mondo del software aziendale in tre regni distinti. Abbiamo i sistemi di record, i sistemi di report e i sistemi di intelligence. I sistemi di record riguardano davvero le immissioni di dati e i flussi di lavoro. Questo comprende tutto ciò che comporta la gestione in un sistema di record, che può essere un CRM, un ERP (che avrebbe dovuto chiamarsi ERM, enterprise resource management, perché la pianificazione è una preoccupazione secondaria), TMS, sistemi di gestione dei trasporti, ecc. Tutti quei sistemi di gestione sono sistemi di record.

La mia opinione è che, una volta che hai un sistema di record che si adatta, che funziona e che non è troppo lento, per quel livello hai praticamente finito. Quello che vedo come trasformazione digitale è che le persone cercano di migliorare cose che in realtà non possono essere migliorate molto. Se hai, per esempio, sei un commercialista, hai già un libro mastro, è buono, non è il più scintillante, ma ha tutto ciò di cui hai bisogno? Sì, ed è questo che fanno quei sistemi di record.

I sistemi di record esistono e vedo che in quelle trasformazioni digitali si discute molto di aggiornare sistemi di record che già catturano praticamente tutto ciò di cui hanno bisogno. Quindi, per me, il valore aggiunto di questo tipo di trasformazione, che tipicamente assorbe più dell'80% del budget, è quasi zero, perché hai già i tuoi flussi di lavoro. Già funzionano. Il tuo software, voglio dire, la prossima interfaccia non cambierà nulla perché si tratta di immissione di dati e simili.

E se hai ciò, funziona e cattura funzionalmente tutto ciò di cui hai bisogno, sei praticamente a posto. E penso che la maledizione di quei fornitori enterprise sia che si rendono conto, specialmente aziende come SAP, che hanno raggiunto un punto in cui il lavoro era fatto. Missione compiuta per il sistema di record, due decenni fa.

E ora, a proposito, puoi spiegare tutto lo spostamento di SAP HANA verso, “Oh, trasformiamo questa cosa”, che ha trasformato un sistema di record in un sistema di report con ogni sorta di strato analitico. Ma la mia analisi è che dovresti semplicemente mantenere la tua linea. Tu sei un sistema di record. E poi ti rendi conto che quando le aziende lo considerano in questo modo, direbbero: “Non dovremmo investire in questo perché la prossima versione consisterà solo in bug, regressioni, nuove formazioni, a meno che i vecchi sistemi non fossero insopportabili perché erano troppo lenti, troppo pieni di errori o non riuscivano nemmeno a catturare quei dati di cui avevamo bisogno. In tal caso, non c’è valore aggiunto.”

E per noi nella supply chain, è davvero importante perché vedo molti clienti che hanno sistemi di inventory management che hanno circa 30 anni. Sono schermi console in bianco e nero, ma funzionalmente fanno il 100% di ciò di cui quelle aziende hanno bisogno. E l’inventory management, sai, non è scienza missilistica. Prendo qualcosa, più o meno uno dallo scaffale. Metto qualcosa sullo scaffale, più uno.

Quindi, quei software sono antichi e, funzionalmente, fanno il 100% di ciò che serve. Qui si tratta, per me, di esempio in cui spendere una grossa somma solo per aggiornare certe cose non porta al risultato che le persone pensano di ottenere investendo in questo tipo di percorso.

Eric Kimberling: Sono d’accordo. E penso che sia per questo che aziende come Palantir e Snowflake, alcuni di questi bolt—non voglio dire che siano sistemi bolt-on, ma sono sistemi progettati per interoperare con altri sistemi di record—sono nati. Quindi, potresti dire: “Il mio sistema di record potrebbe essere obsoleto, ma funziona, e non voglio affrontare tutto il rischio, il costo e lo sforzo di sostituirlo. Ma voglio un reporting migliore. Voglio una migliore intelligence. Forse desidero qualche capacità di AI. Ma lo voglio senza… non ho bisogno di strappare via il sistema di record del back office.”

Quindi, è così che sono nate aziende come Palantir, Snowflake e altre. Creano una soluzione che dice: “Mantieni il tuo vecchio sistema. Noi non ce ne importiamo. Ti forniremo una soluzione che non interferisce con esso. Invece, si basa su di esso e ti offre flussi di lavoro migliori, una migliore AI, un reporting migliore, una migliore intelligence, e tutto il resto.”

Quindi, penso che tu abbia ragione. Queste sono le opzioni che molte volte le organizzazioni e i team non realizzano di avere. Hanno opzioni, perché sentono da altri fornitori: “No, no, no, devi sostituire il tuo sistema di record perché è basato su una tecnologia vecchia. Hai un debito tecnico. Stai per restare indietro.” È tutta una vendita basata sulla paura. E funziona.

Fortunatamente per i fornitori, funziona. Sfortunatamente per i clienti, funziona. Quindi, penso che la chiave sia istruirsi, essere obiettivi, ottenere quell’opinione esterna e obiettiva su quali siano le tue reali opzioni, perché potrebbe essere che lasci il tuo sistema di record in essere, ma aggiungi qualcosa che ti dia maggiori capacità senza tutto quel rischio.

Joannes Vermorel: Plug senza vergogna, questo è esattamente il modello di business di Lokad. È strutturato esattamente come Palantir o Snowflake. Noi facciamo proprio questo per quelle ragioni. Ma ovviamente, non volevo costringerti a dirlo. Ma sì, questo è il mio punto. Il problema con quei sistemi di record è che, quando li tocchi, la quantità di disruption per l’organizzazione è immensa.

Puoi accendere e spegnere uno Snowflake che esegue analisi a lato, sai, niente di che, finché non diventi davvero dipendente da esso per le operazioni quotidiane. Ma fino ad allora, puoi accendere e spegnere questa cosa quanto vuoi. A differenza del sistema di record, dove se lo tocchi e si rompe, scoppia il caos perché improvvisamente non sai a chi pagare, per i tuoi fornitori, chi ti deve soldi dai tuoi clienti, ecc.

Quindi, i sistemi di record sono uno strato molto più sensibile e delicato. Ed è per questo che direi che il lato positivo non è così rilevante, perché se hai qualcosa che è già funzionalmente soddisfacente, l’aggiornamento non farà molta differenza. Ma il lato negativo, se lo rompi, può essere assolutamente immenso.

Recentemente in Francia, abbiamo avuto una grande azienda che è fallita, GiFi, proprio a causa di – ho effettivamente questo documento aperto davanti a me – una cattiva gestione della trasformazione digitale. Un’azienda multimiliardaria che è fallita a causa di una trasformazione digitale mal gestita.

Eric Kimberling: Diciamo che era anche una grande azienda ben nota in Francia, giusto?

Joannes Vermorel: Sì, diciamo che era una delle prime dieci reti retail a livello nazionale.

Conor Doherty: Questa è in realtà una transizione perfetta, perché volevo davvero entrare nel merito di qualcosa che commenti spesso, Eric, ovvero prendere esempi di grandi aziende che tutti conoscono. In realtà, ho una lista davanti a me. Hai scritto e parlato di Lidl, per esempio. Ce l’ho qui: 600 milioni di fallimenti nel tentativo di trasformare il loro sistema ERP. Scusate. Ma ci sono anche in tutto il mondo, non solo in Europa.

Hai DHL che perde centinaia di milioni, Lidl in Germania che perde mezzo miliardo. Asda, GE, Spar. In realtà, ricordo di aver visto un tuo video su Spar. Quindi, ancora una volta, queste sono aziende enormi, pertanto non è un fenomeno localizzato o limitato solo all’Europa o alla Francia, per esempio, o solo a Washington o altro. È quasi come un fenomeno sistemico.

Adesso, non voglio mettermi a dire cosa pensi, ma se ciò è in realtà un problema sistemico tra le aziende enormi, la domanda diventa: c’è qualcosa di intrinsecamente vulnerabile nelle grandi aziende che porta a questo? Mancano di agilità o cosa? Perché queste grandi aziende stanno perdendo così tanti soldi?

Eric Kimberling: È una domanda ottima. Innanzitutto, non lo so. Non potrei dirtelo in entrambi i casi. Sì, sospetto che probabilmente i tassi di fallimento siano leggermente più alti nelle grandi aziende, anche se devo dire che ci sono molte piccole e medie aziende che falliscono anch’esse. L’unica differenza è che non ne si sente parlare perché a nessuno importa.

Nessuno aveva mai sentito parlare di queste aziende prima, ma hanno sentito parlare di Lidl. Hanno sentito parlare di Spar Group. Hanno sentito parlare di Asda, chiunque sia il nome famoso. Ma penso che per rispondere alla tua domanda sul perché le grandi aziende siano più suscettibili a questi fallimenti, direi che le dinamiche in gioco in una grande azienda si prestano al fallimento, in parte a causa del comportamento organizzativo. In parte perché una grande azienda, per esempio, è più propensa a implementare una soluzione grande e complessa perché è una grande azienda complessa e sente il bisogno di una soluzione ancora più grande e complessa.

Quindi è più probabile che vada ad acquistare un SAP o un Oracle o qualche altro grande sistema. Questo di per sé è un fattore di rischio. Aumenta immediatamente il rischio, perché ora hai un sistema grande e complesso che stai cercando di implementare.

L’altra dinamica che si verifica più frequentemente nelle grandi aziende rispetto a quelle più piccole è quella che chiamerei la mancanza di responsabilità. C’è meno visibilità e responsabilità a livello esecutivo. Spesso questi dirigenti hanno così tanto da fare. Si stanno espandendo. Entrano in nuovi mercati e acquistano aziende. Sono concentrati su questioni strategiche e considerano la trasformazione digitale come qualcosa di non strategico, il che è un errore.

E delegano questo all’interno dell’organizzazione. Quella mancanza di responsabilità esecutiva, trasparenza, visibilità e impegno, quel mancato coinvolgimento dei dirigenti, porta al fallimento. Questa è una delle principali cause alla radice. E poi, direi che una terza cosa, una terza dimensione che va contro le grandi aziende, è che esse sono più propense a essere così avverse al rischio da aumentare, in modo ironico, il rischio stesso.

E quello che intendo dire è che dicono: “Beh, se implemento SAP, SAP è un prodotto ben noto. Se assumo Accenture, Deloitte o KPMG, è una società molto conosciuta. Quindi coprirò tutte le basi e mi assicurerò di assumere i nomi blue-chip che mi faranno sentire sicuro che siano gli esperti, che possono gestirlo.”

E poi accade che hai un libretto degli assegni aperto e l’integratore di sistemi prende in mano il tuo progetto perché i tuoi dirigenti non sono particolarmente coinvolti e si fidano dei grandi marchi. E quelle grandi aziende seguiranno la strada dell’implementazione della tecnologia e complicheranno eccessivamente le cose, anche se non ha necessariamente senso per il tuo business, perché è quello che sanno fare. È quello che fanno.

È quello che fanno, e non penso che sia qualcosa di nefando e intenzionale. Ma credo che la mancanza di responsabilità e trasparenza porti le persone a perseguire i propri interessi, il che, quando hai fornitori e integratori di sistemi che agiscono per interesse personale, li spinge a venderti più software. Vogliono fatturarti più ore, e il ROI non entra affatto in gioco. Non importa se offre valore o meno. Verranno pagati.

Quindi, gli incentivi sono disallineati. In una grande azienda, una grande azienda complessa, queste dimensioni sono amplificate perché l’azienda è più grande e c’è di più in gioco. Quindi, penso che queste tre cose siano probabilmente le tre principali che vengono in mente per quanto riguarda ciò che pesa contro una grande azienda rispetto a una più piccola. Anche se devo dire che una piccola o media azienda probabilmente fallirà se non segue i fondamenti di base.

E la buona notizia è che non c’è scienza missilistica o formula segreta per renderle di successo. È in realtà abbastanza semplice, ma le organizzazioni non si prendono il tempo per fermarsi a riflettere e prendere le decisioni giuste fin dall’inizio. Questo porta a molti dei problemi di cui stiamo parlando.

Conor Doherty: Grazie Eric. Joannes, hai commentato una o due volte sulla burocrazia nelle grandi aziende. Potresti ripetere quei pensieri?

Joannes Vermorel: Sì, intendo dire, secondo me le piccole aziende possono fallire perché, sì, mancano delle risorse per avere gli esperti e compagnia bella. Credo che le grandi aziende, che falliscono frequentemente, abbiano tutti gli esperti, ma il problema è che questi arrivano con un’agenda. Tutti quegli esperti sono assunti e portano con sé ogni tipo di agenda.

Talvolta si tratta di agende un po’ stupide, per esempio quando le persone vogliono semplicemente provare una nuova tecnologia perché farà bella figura sul loro curriculum. Quindi non sottovalutare anche il fatto che i tecnici faranno cose tecniche solo per il gusto di sperimentare e smanettare.

Ma inoltre, penso che un problema sia, come hai sottolineato, che la trasformazione digitale non viene vista come strategica. Come effetto a catena di ciò, ho spesso notato che il top management delle grandi aziende non ha alcuna mechanical sympathy.

Quindi, cosa intendo per mechanical sympathy? Non hanno alcuna curiosità per ciò che avviene sotto il cofano, per come quelle cose sono collegate, di cosa stiamo addirittura parlando. Non sto parlando di essere un ingegnere del software esperto, ma stiamo parlando di qualcosa che somiglia a un’app grezza, sai, creare, leggere, aggiornare, cancellare su un database che per caso contiene molte tabelle?

O abbiamo bisogno in tempo reale? Cosa intendiamo per tempo reale? Abbiamo bisogno di microsecondi, millisecondi, secondi o ore? Abbiamo bisogno, ecc., ecc.? Voglio dire, ci sono molte domande relativamente basilari, ma se hai quella che io chiamo totale assenza di mechanical sympathy, allora gli oggetti o oggetti software che manipoli sono completamente astratti.

E per te sono una serie di nomi in codice che non hanno alcun senso. “Oh, abbiamo bisogno del widget ABC20, e per far funzionare ABC20 abbiamo anche bisogno di aggiornare Contoso12.” E Contoso12, oh, ha anche bisogno della cosa numero sette, ecc., ecc.

Voglio dire, è come una lunga lista di nomi in codice che non hanno senso. Poi, se hai questo tipo di ambiente che, direi, si presta molto facilmente a una sorta di cattura tecnocratica. Sai, la prospettiva aziendale viene buttata fuori dalla finestra solo perché, in realtà, le persone d’affari hanno completamente rinunciato alle loro pretese perché non hanno alcuna mechanical sympathy. Quindi non riescono nemmeno a esprimere un’opinione sul fatto se le cose stiano generalmente andando in una direzione allineata o meno con il business.

Scusa, è una risposta lunga, ma questo ingrediente della mechanical sympathy l’ho visto mancare in moltissime aziende. E non richiede tanta competenza. Sai, è come un tizio appassionato di automobili, che si prenderà un po’ di tempo per capire cosa c’è sotto il cofano, così non è pura magia se la macchina va avanti. C’è una certa comprensione dei principali componenti che fanno funzionare tutto ciò.

Eric Kimberling: Sì, assolutamente. È un termine interessante. Non avevo mai sentito parlare di mechanical curiosity, e penso che ritorni a un punto che sottolineo spesso. Penso che siano strettamente interconnessi, e ciò riguarda la responsabilità generale e la curiosità per il prodotto nel suo complesso.

E quindi penso che questo riassuma quello che stai dicendo, cioè la mechanical curiosity. Ma credo che tu stia toccando un punto importante, ovvero che, se non coltivi quella mechanical curiosity, non c’è modo di avere la responsabilità e l’intelligenza giusta per prendere decisioni intelligenti riguardo a questi progetti.

E non avendo quella curiosità pratica e quell’esperienza, non devi essere esperto quanto gli specialisti, ma almeno devi avere sufficiente esperienza per poter gestire quegli esperti, perché è tuo compito gestirli. Non dovrebbero gestirti solo perché sono gli esperti. È la tua azienda. Sei tu a dover convivere con i risultati, quindi gestiscili di conseguenza.

Mi sorprende quante di queste grandi organizzazioni dicano: “Non sono un tipo della tecnologia. Non sono responsabile, lascerò che gli esperti se ne occupino.” Ma si tratta di una trasformazione aziendale, e se la stai facendo nel modo giusto, è davvero una trasformazione aziendale, e devi essere coinvolto, molto coinvolto.

Anche se non sei coinvolto nella mechanical curiosity tecnica, dovresti almeno essere coinvolto nella curiosità operativa. Cosa significherà questo per la mia organizzazione? Come saranno le mie operazioni? In che modo verranno influenzati i lavori delle persone? Voglio questo, va bene, o desidero qualcosa di diverso?

E se non sei coinvolto in questo, l’integratore di sistemi inevitabilmente creerà ciò che ritiene giusto, e questo non corrisponderà alla tua visione e alla tua strategia.

Conor Doherty: Se posso aggiungere anch’io, perché sono d’accordo con entrambi, ma voglio solo fare un breve intervento perché vi ho sentiti parlare di mechanical sympathy più volte. Recentemente, in un podcast diverso con il Supply Chain Connect, un saluto, ho parlato esattamente di quel concetto.

Ci sono stati due punti davvero validi, i benefici diretti della mechanical sympathy. Ovviamente, quando capisci un po’ di software, sai come sfruttarlo al meglio, aumentando così il ROI diretto del suo utilizzo. Ma ti protegge anche dalle affermazioni false dei fornitori.

E lo avevi già detto in precedenza: comprendere un po’ o in qualche modo cosa viene progettato, cosa il software è in grado di fare, può proteggerti da affermazioni fuorvianti da parte dei fornitori.

Joannes Vermorel: Sì, intendo dire, ad esempio, prendiamo gli LLM. Ok, l’IA è fantastica, eccezionale, ok, quindi abbiamo quei modelli linguistici di grandi dimensioni. Qual è il costo per ingestire un megabyte di dati in un LLM, solo per avere un’idea approssimativa?

Indicativamente, per un megabyte, anche se si prende un modello economico, stiamo parlando di fondamentalmente $1, e questo è per il segmento più economico. Ogni volta che vuoi ottenere una risposta, se devi processare un megabyte di dati in input con il tuo LLM, ti costerà $1, anche con il modello più economico.

Se hai questo numero in mente, capirai che ci sono molte cose che sono subito evidenti e rimarranno invisibili per probabilmente più di un decennio. Perché, se pensi: “Ok, ho terabyte di dati, non li processerò per primi tramite LLMs.”

E poi, se ogni volta che qualcuno clicca dovessi pagare $1, facendo un calcolo super basilare si capisce che, ok, questa cosa non può funzionare. Non è economicamente sostenibile.

Anche se il prezzo scendesse di un fattore 100, siamo comunque lontani di quattro zeri rispetto a qualcosa di sensato. Solo un esempio, e ho visto molte situazioni in cui discutevo con potenziali clienti dicendo: “Prendete solo alcuni semplici ordini di grandezza così da capire di cosa stiamo parlando.”

La stessa cosa, ad esempio, per il calcolo distribuito. Il calcolo distribuito è fortemente limitato dalla velocità della luce. Le persone dicono: “Perché dovrei sapere la velocità della luce?” Ma la risposta è: se hai un sistema in cui il tuo magazzino dialogherà con il tuo sistema centrale e le informazioni si scambiano continuamente, hai una latenza di 200 millisecondi.

Ti rendi conto che servono mille viaggi di andata e ritorno per fare qualcosa. Quindi stiamo già parlando di 200 secondi solo per completare questi viaggi. Ancora, non è un calcolo super sofisticato, ma sono il tipo di cose in cui, ok, abbiamo un problema di progettazione.

Non serve essere un ingegnere avanzato, stiamo parlando solo di una semplice moltiplicazione, di poche basi. Ho visto molti progetti dei nostri clienti fallire perché non erano state fatte delle semplici stime basate su regole empiriche.

A quel punto, le persone si renderebbero conto che non funzionerebbe affatto considerando gli obiettivi di business. Perché il tecnico potrebbe dire: “Beh, ci vorranno 200 secondi. Molti calcoli richiedono tempo, perché non 200 secondi?”

Ma l’operatore direbbe: “No, questo è qualcosa per cui un operatore sta aspettando, quindi non è nemmeno possibile.” Oppure l’LLM direbbe: “Oh, costa un megabyte, $1.” L’ingegnere direbbe: “Sì, perché no? Sai, è solo un prezzo, non mi interessa.”

Non importa, e poi il business direbbe: “Ma ti rendi conto che una persona, pagata qualcosa come $20 all’ora, cliccherà questa cosa 60 volte all’ora?” Quindi il costo del tuo LLM sarà circa quattro volte quello che paghi all’operatore.

Ancora, questo è solo, ma ancora, l’unico modo per assicurarsi che abbia senso è avere un’azienda con un po’ di mechanical sympathy coinvolta, una strutturazione del progetto e il relativo valore aggiunto, il valore aggiunto inteso, che diano un senso. Quella sarebbe la mia opinione.

Eric Kimberling: Sì, e solo comprendendo quei costi nascosti e quelle cose che in superficie possono sembrare che stiano realmente migliorando il tuo business. Potrebbe migliorare il tuo business, ma se aumenta in modo drammatico e sostanziale il tuo costo, allora probabilmente non riuscirai ad ottenere il ROI che cerchi.

Joannes Vermorel: Sì, e ancora, non sottovalutare come, per mia esperienza con gli ingegneri: come gli ingegneri possono fornirti cinque numeri di precisione, ma la virgola è solo leggermente spostata nel calcolo.

Quindi è per questo che dico che i dirigenti devono davvero avere questa mechanical sympathy, avere questo interesse per la trasformazione digitale e tutto ciò che la compone. Perché altrimenti, sei nelle mani di tecnologi che sono entusiasti della tecnologia—va bene, perfetta—ma che possono facilmente distrarsi e perdere di vista quegli ordini di grandezza che determinano se otterrai un ROI positivo o meno.

Conor Doherty: Solo per assicurarmi di aver capito, l’impatto che hai menzionato prima: un terabyte è un milione di megabyte, giusto? Quindi processare un dollaro per megabyte sarebbe solo…

Joannes Vermorel: Un terabyte sono mille gigabyte. Quindi sì, è un milione di megabyte. Quindi un terabyte a questo prezzo di cui parlavo costerebbe un milione di dollari per terabyte da processare.

Conor Doherty: Solo per assicurarmi di aver capito.

Joannes Vermorel: Quindi sì, voglio dire, se vuoi farlo, probabilmente non vorresti farlo in primo luogo. E se devi assolutamente farlo, devi davvero assicurarti di non doverlo fare più di una volta all’anno, perché ovviamente, anche per una grande azienda, stiamo parlando di costi IT piuttosto esorbitanti.

Conor Doherty: Beh, sì. In realtà, Eric, se posso tornare su questo, perché il tono generale, l’inquadramento complessivo, era di cose che mancavano. Però vorrei riprendere qualcosa che era assente. Sai, abbiamo già discusso della mechanical sympathy, ma in quell’occasione entrambi avete sollevato l’idea del ROI, del ritorno finanziario.

E qualcosa che hai detto prima, Eric, quando parlavi di aziende, tipo le grandi aziende, che scelgono quale software adottare, “Oh, prenderemo quello, qual è il nome importante? Prenderemo quello. E quale grande società di consulenza? Prenderemo quella perché, sai, casella spuntata.” E hai detto, perché in quel contesto, spesso il ROI non conta. Ora so che Joannes ha già parlato in precedenza di KPI finanziari e ROI nella supply chain, ma mi chiedevo, potresti spiegare un po’ meglio, tipo perché pensi che la prospettiva finanziaria potrebbe non essere presente nella supply chain come forse dovrebbe?

Eric Kimberling: Sì, penso che con la tecnologia che cambia così rapidamente ed esponenzialmente, ci sia quasi una corsa agli armamenti nucleari dove le persone sentono di avere FOMO, sai, la paura di perdersi qualcosa. E vogliono assicurarsi di non soffrire di debito tecnico e di tutti quei termini appariscenti che analisti e fornitori di software inventano.

E così perdono di vista. Penso che, credo, l’industria stia dimenticando perché stiamo realizzando questi progetti tecnologici. Voglio dire, non li facciamo perché vogliamo capacità cloud. Non lo facciamo perché vogliamo l’IA. Non lo facciamo neppure perché vogliamo una maggiore intelligenza, reportistica o un sistema di registro migliore.

Abbiamo perso di vista tutto ciò. Non ci siamo concentrati sul perché ci serve quella tecnologia. Perché, ad esempio, dobbiamo passare al cloud? Voglio dire, a volte chiedo ai clienti questo, e mi danno sguardi perplessi, tipo, uh, perché siamo on prem in questo momento. Dico: “Ok, siete on premise. Allora, qual è il peggio che può succedere se restate on prem per altri cinque anni?”

Beh, sai, allora non saremo nel cloud, oppure il fornitore del software interromperà la manutenzione. Ok, aspetta un attimo. Ne parliamo. Forse interrompono la manutenzione, qual è il peggio che può succedere? Beh, dobbiamo occuparcene noi, e non possiamo contattare il fornitore per supporto. Ok, allora potreste dover assumere qualcuno.

Vediamo. Ma osserviamo quell’opzione, perché potrebbe in realtà rappresentare un rischio molto inferiore per voi rispetto a una trasformazione colossale da 600 milioni di dollari, come ad esempio nel caso di Lidl.

Quindi le aziende non lo fanno abbastanza perché sentono di doverlo fare. Sentono di dover fare un aggiornamento. Devono passare al cloud. Devono avere l’IA, bla, bla, bla. Quindi penso che tutti i cambiamenti tecnologici e la rapidità con cui avvengono facciano sì che le aziende si perdano, si confondano e dimentichino perché stanno intraprendendo questi progetti fin dall’inizio.

Joannes Vermorel: Penso che, voglio dire, i KPI finanziari in prima istanza siano in qualche modo fuorvianti perché non credo sia l’approccio giusto. Il tuo percorso digitale, per così dire, è come 10 anni. Devi pensare a 10 anni in avanti—dove vuoi essere? Quelle cose hanno una lunga durata. Sono letteralmente le aziende che stai progettando.

Quindi, secondo me, considerare KPI di breve termine non è davvero rilevante per decidere se sia la scelta giusta o meno. È proprio il tipo di approccio che, se lo seguissi, ti farebbe dire, tipo, Walmart, anno 2002, “Oh, no, e-commerce, non ci interessa.”

Esattamente quel tipo di ragionamento che ti porta a dire, “Ok, l’e-commerce è rilevante; è così piccolo che non ci interessa.” No, in realtà è molto rilevante, e ci sarà un gigante che sarà semplicemente più grande di te in pochi anni se non fai nulla. Una trasformazione digitale mancata. Voglio dire, il grande retail chain avrebbe potuto diventare il gigante dell’e-commerce; non è accaduto perché, in un certo senso, hanno mancato la trasformazione digitale.

Ma, tornando a dire, direi che non sono molto per questo, sono più propenso a pensare da una prospettiva aziendale a lungo termine. Abbiamo un calcolo sommario che ci dica che questa è la cosa giusta da fare? Adeguato al rischio, dicendo, sai, pensi che il rischio sia del 90%, 50% o 10%, e cercare di avere quell’assunzione semplice solo per giustificarlo e orientarci in quella direzione.

E ora penso che ciò che tipicamente manca è che, ancora una volta, ho menzionato l’incrementalismo. Le persone considerano la loro trasformazione digitale come la stessa cosa, ma un po’ migliore. Ancora, se torniamo a Walmart 2002, il futuro è l’e-commerce, quindi non è affatto lo stesso che solo Walmart con un punto vendita leggermente migliore con schermo LCD.

Non è così, vedi, questo è il punto. Il futuro è fondamentalmente qualcosa di diverso, e penso che sia proprio lì che le aziende di solito non intervengono abbastanza per sfidare l’idea di come sarà l’azienda tra 10 anni. Che tipo di ruoli? Penso che ci sia stato un memo molto interessante del CEO di Shopify che circolava recentemente su LinkedIn.

Lui stava letteralmente dicendo a tutti, “Per ora sospendiamo tutte le assunzioni, e ogni dipartimento dovrà giustificare che ciò per cui desiderano assumere non può già essere fatto con le tecnologie AI, LLM e quant’altro abbiamo già acquisito, implementato e integrato nel nostro sistema.” Shopify è un’azienda piuttosto high-tech, quindi hanno già diversi anni di esperienza in questo ambito.

E lui diceva, “Ok, abbiamo un problema in termini di trasformazione. Chiaramente, l’essenza del memo era che il management più ampio non si stava attenendo a prospettive troppo incrementali, invece di essere molto più ambizioso sull’obiettivo finale.” E penso che il messaggio fosse molto interessante. Non dicevano, “Non investiamo, non assumiamo.” Dicevano, “Devi avere un obiettivo finale che riconosca che quelle tecnologie esistono e non dovresti cercare di seguire una traiettoria che finge il contrario.”

Questo era il caso del memo, ed era molto interessante. Vedo molte grandi aziende per le quali la visione a 10 anni dell’azienda digitalmente trasformata, qualunque cosa significhi, è la stessa cosa ma con un’interfaccia utente leggermente migliore. E per me, questo è davvero deludente.

Pensa a 10 anni nel futuro: devi immaginare qualcosa in cui metà dei lavori, soprattutto quelli d’ufficio, che esistono oggi non esistano più. Non significa che devi licenziare le persone; puoi riqualificarle, riassegnarle, e così via. Ma i lavori stessi, almeno la metà di essi, tra 10 anni, semplicemente spariranno, e spariranno.

Eric Kimberling: Sì, e penso che tu stia toccando un punto davvero importante, ovvero, per le persone che ascoltano e che stanno guidando iniziative tecnologiche o di trasformazione nelle loro supply chains o ovunque lavorino, penso sia importante chiedersi: Che cosa vogliamo che sia questa iniziativa? Serve questa iniziativa a sostituire la vecchia tecnologia e semplicemente a mantenersi aggiornati, che forse è più un approccio incrementale, idealmente a basso costo ma potenzialmente con un ROI inferiore? Oppure stiamo cercando di trasformare il nostro business, di trasformarlo veramente, e guardare a nuovi modelli di business e all’innovazione? Sono due percorsi molto differenti, e nessuno dei due è giusto o sbagliato. Basta assicurarsi di essere allineati e di prendere decisioni che si adattano al percorso che si sta seguendo. Non dovrebbe essere una soluzione adatta a tutti; dovrebbe basarsi su chi sei. La strategia digitale di Shopify dovrebbe apparire molto diversa dalla tua, dalla mia o da quella di chiunque altro.

Joannes Vermorel: Sono molto d’accordo, ma il problema che vedo è che il percorso numero uno, ovvero il semplice aggiornamento incrementale a basso ROI, è quello che genera budget massicci.

Eric Kimberling: Sì.

Joannes Vermorel: Sì, e per me è come se questo progetto, se fai anche solo un ragionevole calcolo sommario, il ROI risulti essere molto modesto. Perché spendere? Ho visto aziende, e non rivelerò nomi, ma ho avuto discussioni con aziende che affrontano aggiornamenti ERP da oltre 100 milioni di dollari per progetti che durano più di cinque anni. Quando ne parlo con il top management, è molto difficile capire se ci sarà un ritorno—non solo in termini di ROI, ma un ritorno in generale. Una volta aggiornato, il business sarà effettivamente migliore? Non è nemmeno chiaro, specialmente se devi rispettare requisiti hardware come quelli di SAP HANA; voglio dire, sto solo portando in ballo SAP; non sono gli unici.

Conor Doherty: Dai, va bene.

Joannes Vermorel: Sì, ma se congeli il tuo reparto IT per cinque anni, solo il costo opportunità è immenso. Non può essere qualcosa di incrementale; deve essere ben di più.

Conor Doherty: Quindi, Eric, se posso riprendere quel punto, perché letteralmente, Joannes, cosa ho appena scritto lì—costo opportunità di primo ordine, costo opportunità di secondo ordine—letteralmente avevo usato quelle stesse parole per risponderti. Eric, ancora come consulente, stavo per chiederti: come spieghi esattamente il concetto di costi di primo e secondo ordine? Perché ovviamente, il costo di primo ordine: compri questo software, ti costerà 50, 100, 150 milioni; poi dovrai assumere persone per supervisionarlo, il che costerà altri x milioni, per quel che è. Quello è il costo di primo ordine.

Il costo di secondo ordine è, come ha appena detto Joannes, il costo opportunità. I soldi che hai appena speso per quello non li puoi più spendere altrove, perché un dollaro qui non può essere speso contemporaneamente altrove.

Joannes Vermorel: Il tuo team IT è sommerso, congelato in questa faccenda per un determinato periodo di tempo.

Conor Doherty: Questo, ancora una volta, si ricollega alla prospettiva finanziaria di cui parlavo prima. Come spieghi personalmente, quando sei in una stanza in qualità di tech agnostic, per aiutare le persone a capire—e non intendo essere condiscendente, intendo letteralmente—che prendi un dollaro e non puoi comprare due barrette di cioccolato se una costa un dollaro e l’altra costa un dollaro; non puoi comprarle entrambe con un solo dollaro. Quindi, costo opportunità di primo ordine e di secondo ordine, come affronti questi argomenti in maniera che risuonino davvero con chi, come hai detto, ha FOMO—non vuole perdersi nulla, vuole cavalcare l’onda, ecc.?

Eric Kimberling: Stai alludendo a qualcosa di cui non abbiamo ancora veramente discusso o approfondito nei dettagli, ovvero le aspettative realistiche e il mantenere aspettative realistiche riguardo a quei costi di primo e secondo ordine. Penso che la causa principale, o una delle cause principali del problema, sia che le organizzazioni non capiscano qual è il costo reale, e pertanto non possano valutare quei costi opportunità, perché pensano che costerà 100 milioni quando in realtà non sarebbe mai costato 100 milioni; sarebbe sempre costato 300 milioni. Ma qualcuno ti ha convinto che si potesse fare per 100 milioni, e quella persona ti stava sovrastimando, sottovalutando l’impegno, sapendo che ci sono complessità e rischi che probabilmente aumenteranno il costo. Se ci pensi, quando un fornitore di software o soluzioni ti vende una soluzione, non gli conviene, da una prospettiva egoistica, sovrastimare il costo. Quello che li aiuta è sottostimare e dire, “No, no, è a basso rischio, a basso costo.” Quindi il problema inizia da lì.

Quindi, ok, se dico che valuterò i costi opportunità, quei costi di secondo ordine, li valuto con informazioni errate. Anche se lo faccio, non importa, perché non ho informazioni accurate per prendere quella decisione. Ma penso che se più aziende conoscessero quale sarebbe realmente il costo, allora direbbero, “Whoa, aspetta, è una cifra enorme. Sono soldi che potremmo usare per costruire un’altra fabbrica. Potremmo aprire 10 nuovi negozi per lo stesso costo. È davvero ciò che vogliamo?” La maggior parte delle organizzazioni non arriva a quel punto decisionale perché si basa su un costo sottostimato che non è mai stato realistico.

L’altra cosa, inoltre, beh, c’è un’altra questione che—e pensavo forse fosse qui che voi stavate andando con il costo di primo e secondo ordine—ma un altro costo di cui non abbiamo ancora parlato è la interruzione operativa. Sai, cosa succede quando adotti una nuova tecnologia per la prima volta, non importa quanto bene venga gestito il progetto? Ci sarà un calo della produttività in qualche modo. Ora, si spera che non sia un crollo totale della produttività; troppo spesso lo è. Ma anche se lo gestisci davvero bene, avrai comunque qualche interruzione.

Quindi, qual è il costo di questa interruzione e cosa succederebbe, per esempio, se non potessi spedire prodotti per due settimane, quattro settimane, tre mesi? Succede alle organizzazioni: attraversano questi progetti, qualcosa va storto, entrano in produzione e poi non possono spedire i prodotti. I clienti si arrabbiano, annullano gli ordini. Questi sono i costi reali. Questi sono i costi che devi includere nel tuo ROI, così puoi ottimizzare la tua implementazione, assicurarti di gestirla bene e di capire qual è il vero rischio.

Conor Doherty: Hai sollevato un punto davvero buono, Eric, e Joannes, vorrei tornare su di te per riprendere l’esempio che Eric ha appena fatto. Per esempio, se prendessi qualcuno—e non voglio puntare il dito contro nessuno in particolare—ma se prendessi il livello medio dell’industria automobilistica, aerospaziale o del petrolio e del gas, e dicessi, “Quanto costa in termini di perdita di produttività un’ora di downtime?” Sarebbero in grado di darti un ordine di grandezza approssimativo, ma i tipi di downtime che Eric ha appena descritto potrebbero non essere quantificabili.

Joannes Vermorel: Sì, e penso anche che per il costo operativo sia completamente azzeccato. Una cosa che le persone non si rendono conto è che la produttività diminuisce quando la complessità del tuo ambiente aumenta. Quindi, vedi, hai un pezzo di software; è antiquato, fa pochissime cose, ma fa ciò di cui hai bisogno. Ciò significa che, in termini del mio ambiente IT, la mia interfaccia utente non ha così tanti pulsanti, non offre tante opzioni, non dispone di così tanti fronzoli e funzioni che posso usare. Ora, però, aggiorno a qualcosa di molto più potente. Perché? Perché il fornitore, c’erano così tante caselle da spuntare nell’AFP. Abbiamo chiesto al fornitore, “Deve poter fare questo, quello, questo, quello, e così via, ok, 100 caselle dopo.” Ora abbiamo il sistema aggiornato che può fare in aggiunta una miriade di cose.

Ma ciò significa che per la persona che utilizza il software, ci sono molti più menu. E ho visto questo ripetersi continuamente nei software aziendali, dove le persone mi mostrano il software e io dico, “Questo è orribile.” È come se avessi 30 menu, e poi quando clicco su uno qualsiasi di essi, ogni menu ha circa 30 sottomenu, e forse ogni sottomenu ce ne ha circa cinque. E poi hai una schermata a muro con 20 opzioni diverse sullo schermo.

E così, ciò che ho osservato molto frequentemente è che le persone aggiornano un software, soprattutto quei sistemi di registrazione, verso uno nuovo e migliore. Sì, l’interfaccia utente è più gradevole, ma ha moltissime funzionalità in più che in realtà riducono la produttività, semplicemente perché le persone si perdono in un labirinto di opzioni. Ed ecco la cosa interessante: nel software aziendale, avere di più non è necessariamente meglio, soprattutto quando si tratta di funzionalità che non usi.

Ogni singola funzionalità in un sistema che non utilizzi è solo un peso morto. Vuol dire che confonderà ogni nuovo assunto che verrà a utilizzarlo. Diranno, “Perché non funziona?” Ah, perché ci sono come cinque schermate differenti per effettuare gli ordini di acquisto, ma noi ne usiamo solo una delle cinque. Le altre quattro, no, sono solo vicoli ciechi. Se inserisci i tuoi dati lì, non verranno elaborati; saranno semplicemente persi e ignorati. Questo è il genere di situazioni che potresti incontrare.

Eric Kimberling: Sì, assolutamente. Voglio dire, è un punto davvero valido e ciò ci riporta a definire esattamente ciò di cui hai bisogno. Voglio dire, hai bisogno di tutta quella tecnologia? Spesso le aziende si mordono più di quanto possano gestire, e si impegnano eccessivamente nelle spese tecnologiche. E poi si crea così tanta complessità solo sul fronte tecnico che non hai il tempo o le risorse.

Tornando al tuo punto sul costo opportunità, ora non hai il tempo o le risorse per investire nelle cose che contano davvero. E le cose che contano sono: ottimizzare i nostri processi aziendali, assicurarci che il personale sia ben formato, ottenere una buona adozione, ridefinire i ruoli e le responsabilità delle persone per adattarli alla nuova tecnologia e al nuovo modello operativo.

Queste cose sono ciò che fa o distrugge un sistema o una trasformazione. Eppure, le aziende stanno sovrainvestendo in tecnologia. Preferirei di gran lunga vedere un’azienda che compra solo una piccola parte di tecnologia ma la implementa davvero bene, perché quell’azienda avrà più successo. Ridurrà il rischio e probabilmente otterrà un ROI migliore.

E poi, una volta fatto anche quello, per inciso, una volta che investi quella piccola somma in tecnologia e la gestisci davvero bene, costruisci fiducia, capacità e maturità all’interno della tua organizzazione fino al punto in cui puoi dire, “Ok, ora mi accingo a un progetto più grande. Ora sono convinto che abbiamo imparato abbastanza da poter investire in un po’ più di tecnologia.”

E invece di acquistare un unico sistema gigantesco, spendere tutti questi soldi, e poi sentire la pressione di implementarlo tutto perché lo abbiamo pagato, creando così tutta questa complessità, e poi non investire in adozione e miglioramento dei processi, tutte le cose importanti. Ed è qui che molti di questi progetti sfuggono al controllo.

Conor Doherty: In realtà, e ancora, proprio come ha detto Joannes prima, hai anticipato esattamente ciò che ho appena scritto come prossima domanda o come seguito. Abbiamo discusso a lungo dei problemi e delle insidie da evitare. Ma questo richiama veramente il concetto di implementazione e gestione del change management, il processo di change management.

Quindi, Eric, prima rivolgo a te, in una nota più positiva: ci sono cose che hai osservato nelle trasformazioni digitali di successo, soprattutto nel contesto della gestione del change management, della cultura, delle aspettative, ecc.? Quali sono gli elementi che realmente aiutano in questo senso?

Eric Kimberling: Sì, voglio dire, torno al termine che hai usato—onestà—hai detto che era mechanical sympathy, simpatia? Io intendevo mechanical curiosity nella mia mente. In realtà, entrambi funzionano, ad essere onesti. È in un certo senso lo stesso. Mechanical sympathy—lo so, l’ho sbagliato prima. Ma mechanical sympathy è davvero importante.

Perché i progetti di maggior successo che abbiamo visto sono quelli in cui i leader aziendali dell’organizzazione sono coinvolti attivamente. Comprendono la tecnologia; potrebbero non essere esperti in configurazione e programmazione, non è necessario che lo siano, ma sanno come funziona la tecnologia. E capiscono sicuramente come funziona la loro azienda e come vogliono che funzioni.

Quella mechanical empathy porterà a una maggiore responsabilità e a risultati più guidati dal business piuttosto che dalla tecnologia. Quindi, è una cosa che vediamo spesso: la proprietà del progetto, il coinvolgimento diretto dei leader aziendali.

L’altra cosa è, immagino, in qualche modo collegata a questo: non esternalizzano la trasformazione. Non dicono semplicemente, “Faremo entrare grossi fornitori e li lasceremo gestire tutto.” Dicono, “Faremo entrare degli esperti, ma li gestiremo.” Proprio come gestiresti un subappaltatore o un appaltatore generale se assumessi qualcuno per costruire una nuova fabbrica.

Probabilmente non diranno, “Non ci interessa, vai a costruire la fabbrica, usa le best practices, fai ciò che serve per costruirla.” No, saranno pesantemente coinvolti, assicurandosi che la fabbrica rispetti le specifiche e così via. Ma con i progetti tecnologici, molte aziende non lo fanno. Quindi le aziende di maggior successo trattano gli investimenti in tecnologia e le trasformazioni proprio come qualsiasi altro investimento in capitale.

Non la trattano in maniera diversa; si aspettano un ROI, limiteranno il budget, saranno pesantemente coinvolti, avranno molto da dire su come procedere. Quindi tutto ciò avviene sin dall’inizio, ed è un fattore chiave per il successo.

Un altro punto, tornando a quanto detto da uno di voi in precedenza, riguarda le decisioni prese fin dall’inizio. Non voglio dire che l’esecuzione non importi, perché importa, ma ciò che è ancora più importante sono le decisioni che precedono l’esecuzione effettiva: le decisioni prese, le priorità fissate, l’allineamento.

Ottenere l’allineamento all’interno del team, perché molte volte, quando entri in una stanza con, ad esempio, sette dirigenti e hai il nostro comitato direttivo presente, e se chiedo loro, “Cosa significa questa trasformazione per l’organizzazione?” di solito otterrai sette risposte diverse. E nessuna di esse è esattamente giusta o sbagliata, ma tutti dicono cose differenti, e non si può avere successo.

Non avrai successo, non importa chi assumi, non importa in quale tecnologia investi, non avrai successo se non siete tutti sulla stessa lunghezza d’onda. È un processo complicato e, in teoria, potrebbe rallentare il progetto nel breve termine perché ora stai dicendo, “Aspetta, fermiamo la tecnologia, non facciamolo ancora, allineiamoci prima.”

Le persone pensano, “Beh, ma dobbiamo iniziare oggi.” Sai, siamo già in ritardo, dobbiamo andare, e noi rispondiamo, “Beh, rallenta, perché se ti precipiti, finirai per precipitare da una scogliera. Quindi assicurati di non cadere; prenditi il tempo extra per chiarire il percorso e poi mettiti d’accordo.”

Quindi, quell’allineamento e il prendersi il tempo per stabilire obiettivi strategici, parametri, priorità, il business case, le aspettative, la governance, definire i nostri futuri processi aziendali—come vogliamo che siano i nostri processi in futuro? Come vogliamo che sia l’organizzazione in avanti? Tutto ciò deve essere definito in anticipo, prima di iniziare a implementare la tecnologia, ed è un fattore di successo davvero importante.

E infine, l’ultimo punto che menzionerò riguarda l’investimento nel change management. Le aziende che investono pesantemente, e quando dico investire pesantemente non intendo necessariamente una grande somma di denaro, intendo che stanno investendo tempo e concentrandosi sul cambiamento organizzativo, sulla comunicazione, sull’adozione, sulla chiarezza per l’organizzazione. Tutto ciò aumenta drasticamente il tasso di successo.

Joannes Vermorel: Sono d’accordo con il tuo aneddoto. Infatti, nel software, sai, sono anche un ingegnere del software. C’è questo detto: “Oh, ho passato tre ore a pensare al problema che volevo implementare. Ho passato tre ore, e mi è costato tre settimane di implementazione extra.”

Ma tornando al caso iniziale, vedo molte aziende, sai, le grandi aziende adottano questa idea, “Oh, sì, dobbiamo pianificare attentamente.” Hanno sentito questo consiglio; non siamo i primi a dirlo. Quindi lo fanno, ma vedo una perversione di questo modo di pensare, pur essendo d’accordo che sia la strada giusta. Bisogna pensare in modo molto chiaro e prendersi un po’ di tempo, probabilmente, in questa fase che è estremamente critica.

Ma quello che ho visto è che molte grandi aziende corrompono questa idea nella loro organizzazione trasformandola in un esercizio di spuntare le caselle o in un esercizio burocratico tipo, “Oh, siamo in fase di pianificazione, quindi mi serve questo rapporto e questo rapporto e questa validazione e questo audit e questa missione di diagnosi e questo e questo e questo.” E ciò che ne risulta non è chiarezza; ciò che ne risulta è un documento che può essere lungo migliaia di pagine e che non offre alcuna chiarezza. È quello che io chiamo tecnocrazia.

È questa fase di pianificazione in cui finisci semplicemente per raccogliere informazioni dall’organizzazione, e tutti tendono a soddisfare eccessivamente la richiesta. Quindi immagina di essere il consiglio di amministrazione e che, in un mese, i tuoi team abbiano raccolto diverse migliaia di pagine di valutazione, diagnosi, ecc. E nessuno ha alcuna idea del contenuto. È un po’ come il disegno di legge sugli stanziamenti omnibus del Congresso negli Stati Uniti. È come un documento massiccio, lungo migliaia di pagine, e nessuno ha la minima idea di cosa vi sia dentro.

La mia opinione è che in questa fase di pianificazione si debba comprendere che le persone non dovrebbero trattare questo esercizio come qualcosa di puramente tecnocratico. Devi riuscire a mantenere la chiarezza in un documento che, probabilmente, dovrebbe essere lungo al massimo tra cinque e venti pagine. Se non riesci ad avere qualcosa di chiaramente espresso in al massimo 20 pagine, idealmente anche meno, allora probabilmente sei semplicemente perso in un labirinto tecnocratico.

Il tuo percorso sarà molto sbagliato in seguito. E dico pagine scritte in testo, non in PowerPoint, perché con i PowerPoint puoi imbrogliare con i punti elenco—non c’è alcuna connessione logica, quindi puoi ottenere qualcosa di super ambiguo. Se scrivi in inglese con una corretta segnalazione e connessione, allora non puoi imbrogliare; devi avere qualcosa che abbia senso e un documento che tu possa leggere ad alta voce. Questo è, in un certo senso, il mio punto di vista su questo modo di pensare.

Eric Kimberling: È un ottimo punto. E il team che esegue il progetto deve avere quella chiarezza. Sai, se pensi a una supply chain transformation, supponiamo che tu sia un’organizzazione che sta per implementare una complete supply chain technology. È facile perdersi in un sacco di complessità e dettagli.

Se lo tratti come una sorta di democrazia in cui ognuno ha voce in capitolo, con priorità, richieste e tutto ciò che desidera dal sistema, il progetto finirà per sfuggire al controllo. Hai bisogno di una governance che dica, “Sai una cosa? Sì, stiamo facendo la supply chain transformation, ma gli acquisti non sono la nostra massima priorità in questo momento. Invece, ciò che conta è la supplier management, è la vendor management.”

Perché, indovina un po’? Il governo degli Stati Uniti sta imponendo tutte queste tariffe adesso, o ci sono tutte queste questioni geopolitiche che dobbiamo gestire, quindi abbiamo bisogno di una supplier management migliore, ed è questo il nostro focus. Devi dare priorità e dire, “Lo facciamo perché vogliamo rivedere i nostri processi di supplier management” e gestirlo di conseguenza.

Se non hai quella chiarezza in quel documento di 5-20 pagine e non riesci a mettere tutti d’accordo, allora si trasformerà in una sorta di anarchia in cui ognuno chiede qualunque cosa pensi di volere.

Joannes Vermorel: A proposito, per la cronaca, ho visto molte aziende, e non ho mai visto documenti di alta qualità se non quelli trapelati da aziende tecnologiche americane come Amazon, Shopify, Apple—promemoria trapelati che sono super chiari, scritti in cinque pagine, magnificamente redatti. Si vede che il management ha davvero una comprensione acuta di dove si trovi, di dove voglia andare, ecc., e scrivono in modo molto chiaro e conciso.

Quando si passa alle aziende non tecnologiche, è estremamente raro vederlo. Estremamente raro. Riesco forse a pensarne solo in una dozzina. Berkshire Hathaway, per esempio, i loro promemoria sono assolutamente brillanti; è chiarissimo cosa stanno facendo, perché, ecc. Ma tipicamente, per aziende come quelle che abbiamo menzionato, tipo Lidl e simili, sono al 100% sicuro che nessuno abbia un semplice promemoria su cosa stiamo davvero cercando di ottenere qui. Perché siamo convinti che questa soluzione abbia una chance ragionevole di successo?

La maggior parte di quei grandi progetti che sto osservando—Lokad vi partecipa talvolta—sai, aggiornano il loro ERP, aggiornano la loro supply chain analytics con noi. È davvero così raro; è per questo che lo menziono. Quasi mai vedo alcun grado di chiarezza quando si parla di trasformazione digitale. È solo strato su strato di tecnocrazie.

Ancora, hai menzionato l’outsourcing—anche imprese che sono completamente esterne all’azienda. Quindi quei documenti, lunghi migliaia di pagine, per metà verrebbero forniti da fornitori terzi.

Eric Kimberling: Mi chiedo se sia davvero interessante quello che dici sulle aziende tecnologiche. Non ne ero a conoscenza, o non avevo fatto quella connessione prima. Sai, forse le aziende tecnologiche sono più capaci e mature nella loro capacità di fornire quella chiarezza.

Ma mi chiedo, a volte mi chiedo se, sai, gli esecutivi di oggi—pensa agli esecutivi che sono cresciuti nello spazio tech dagli anni ‘90, ok, forse hanno la mia età o un po’ più anziani. Ricordo che è uscito Windows 98, ed è stato un evento così importante quando Windows 98 è stato lanciato.

È stata una specie di sconvolgimento per molte aziende perché hanno dovuto affrontare questi grandi aggiornamenti di Windows. Ma alla fine della giornata, era un aggiornamento di Windows; non era una trasformazione. Era, “Abbiamo bisogno di nuovi sistemi operativi per i nostri PC, desktop e laptop.”

Mi chiedo se gli esecutivi cresciuti nello spazio IT in quel periodo pensino ancora ai progetti tecnologici come a un aggiornamento a Windows 98, e non riescano a riconoscere che questo non è un aggiornamento a Windows 98. Questo è un cambiamento radicale non solo dei tuoi sistemi back-office e dei database, ma dei tuoi processi, del tuo modo di essere organizzato, tutto ciò.

Questa è solo una pura ipotesi. Non so se sia vera o meno, ma sto cercando di arrivare alla radice di ciò di cui stiamo parlando per capire perché sia così.

Joannes Vermorel: La mia opinione è che, quando guardo ai piani di trasformazione digitale per la maggior parte delle aziende non tech, di solito, in quanto tecnologo io stesso—Lokad è una società di software che fa essenzialmente decision-making robotizzato per supply chain—quello che vedo è che quelle trasformazioni digitali mi sembrano estremamente contenute.

Quando penso alla trasformazione digitale per la mia azienda, perché quelle tecnologie, come hai detto, stanno evolvendo e molte cose stanno cambiando per Lokad, vedo un futuro a 10 anni in cui forse più della metà dei lavori che abbiamo spariranno in termini di compiti. Le persone ci saranno ancora, nessun problema, ma faranno cose diverse.

Quando guardo alle classiche aziende non tech—pensa a un’azienda aviation, a un’azienda manifatturiera, a un’azienda retail, a un’azienda di moda—sai, aziende per le quali la tecnologia è solo qualcosa di secondario, quando esamino la loro trasformazione digitale, essa è molto, molto contenuta.

Non c’è quasi nessun lavoro eliminato, nessun compito cancellato a priori. Quando pensi a cosa strumenti come, ad esempio, ChatGPT possano fare, vedi che esistono intere classi di compiti che ovviamente possono essere automatizzati.

Comunque, la mia opinione è che le trasformazioni digitali mancano molto spesso di ambizione; sono estremamente contenute. L’unica cosa che non è contenuta è il budget a disposizione per fare l’aggiornamento.

Conor Doherty: Scavalco il discorso e mi baso su questo perché penso che, in fondo, sia come aprire dei loop. Se torniamo al vero e proprio loop aperto, il pensiero fondamentale, in termini di mentalità e di come inquadriamo persino il problema per tornare al cerchio completo, è il problema che stiamo cercando di risolvere. Joannes, passo prima a te e poi ad Eric per un commento.

Joannes, in realtà ho introdotto questo spunto in background perché qualcosa che Eric ha detto prima riguardo capex vs. opex mi ha ricordato una lezione che hai fatto sulla delivery orientata al prodotto per supply chain, in cui sostenevi che la supply chain non è una supply chain opex. Dovrebbe essere ricategorizzata come capex trattata come un asset, e mi viene da pensare che inquadrare quel problema in modo semplice, cioè non trattarlo come se la supply chain e tutti i suoi costi associati fossero, beh, giusto come biscotti o penne – cose di cui ho bisogno per affrontare la giornata – trattandola più come un asset che può scalare e apprezzarsi in valore potrebbe essere un modo più utile per avviare la discussione, sia che si tratti di assumere persone o di cercare software. Quindi, potresti forse approfondire un po’ quella distinzione?

Joannes Vermorel: Sì, beh, è una mia opinione personale. Quando guardo ai lavori d’ufficio, a meno che non ci sia qualcosa di veramente speciale, penso che siano semplicemente dei costi che l’azienda deve sostenere per ottenere un certo output in termini di trasformazione dell’informazione. Un lavoratore d’ufficio è fondamentalmente qualcuno che prende informazioni in ingresso e produce informazioni in uscita che possono assumere molte forme. Ma molte persone, soprattutto nel back office, fanno esattamente questo nelle grandi aziende. Nella supply chain, ad esempio, hai persone che prelevano i livelli di stock dal loro ERP e tanti indicatori delle vendite recenti e così via, e cosa decideranno? Decideranno, per ogni singolo SKU, storage keeping unit: “Devo riordinare, sì o no?” Ho mille SKUs da gestire. L’organizzazione è suddivisa in modo tale che un supply e un demand planner gestiscono, diciamo, 1.000 SKUs. In totale abbiamo 80.000 SKUs, quindi sono 80 supply e demand planners, e ognuno di loro ogni giorno esamina 1.000 SKUs ed emette l’ordine di replenishment per il giorno. Molte aziende sono organizzate esattamente così.

Quindi, la mia opinione è che, quando consideri la tua supply chain practice in questo modo, le persone che hai sono puro opex. Devi sostenere quei salari ogni giorno affinché la tua azienda non smetta di operare. Se smetti di pagare quelle persone, esse smettono di lavorare, l’azienda si ferma, il flusso delle merci si interrompe. Se pensi che il modo in cui Lokad si approccia ad esso sia dire, “No, dovremmo considerare la supply chain practice come qualcosa che è capex. Abbiamo persone che ingegnerizzano software, in un modo o nell’altro. Ci sono un sacco di modi; low code, non devi necessariamente programmare, ma ingegnerizzi software che genera automaticamente quelle decisioni di replenishment.”

E poi, se devi pagare una persona in più, è per migliorare il sistema. In questo caso, il tuo investimento è capex. Hai questo pezzo di software che funziona automaticamente, e hai l’opex, ma è solo per il software, quindi la spesa è molto contenuta. E quando spendi soldi sulle persone, è per migliorare il sistema, ed è quindi molto capitalizzante. È accrescitivo; è come dovrebbe essere un asset. Sì, diventa un asset. Così, il tuo investimento nelle persone diventa un asset; l’output di quelle persone è un asset tangibile per la tua azienda, che risulta essere questo sistema decisionale.

Quello che vedo nelle moderne trasformazioni digitali è che sembrano estremamente contenute nel senso che ci sono tonnellate di lavori da ufficio puramente opex che dovrebbero diventare capex. Quando le persone lavorano per un’ora, producono qualcosa che è accrescitivo, qualcosa che costruisce un asset di qualche tipo, probabilmente software, ma può essere anche qualcos’altro che ha valore per l’azienda, indipendentemente dal lavoro continuo delle persone. Può sembrare un po’ strano, ma è come se quelle persone stessero ingegnerizzando la macchina, e poi potessi farla funzionare indefinitamente. Sto semplificando, ovviamente; quelle macchine richiedono manutenzione e via dicendo, ma la maggior parte delle trasformazioni digitali che vedo sono estremamente contenute perché si limitano a considerare quelle persone usate come opex, cioè puramente consumabili. Ho bisogno di riutilizzare quelle persone ripetutamente.

Sto parlando di compiti puramente informativi, non di girare hamburger in un ristorante. Per quello, ci vogliono mani. Non abbiamo ancora robot capaci di girare hamburger. Ma parlo di qualsiasi cosa che somigli a un lavoro d’ufficio back-office. Per me, la maggior parte delle trasformazioni digitali si limita a non affrontare il fatto che queste attività dovrebbero per lo più essere completamente robotizzate, nel back office, quindi non siamo nemmeno di fronte ai clienti. È pura burocrazia interna, eppure, per molte grandi aziende, facilmente due terzi della forza lavoro d’ufficio sono impegnati in mansioni amministrative interne. Molto spesso, vedo che queste trasformazioni digitali non riescono nemmeno a grattare la superficie per quanto riguarda l’enorme quantità di opex che dovrebbe trasformarsi in capex, ma questa è una mia opinione molto personale.

Eric Kimberling: Stai toccando un punto davvero interessante e una sfida ancora più grande, credo, nell’industria tecnologica, nello spazio della tecnologia per le imprese in generale. Hai parlato molto di capex e opex e di trattare l’IT come un asset, ma se guardi dove si dirigono i fornitori di tecnologia, loro si stanno orientando verso un modello in cui non diventa un asset per i loro clienti; diventa l’asset per il fornitore. E lo è sempre stato, ovviamente; è il loro prodotto, è il loro IP. Ma ciò che sta accadendo è che ci stiamo spostando dall’on-premise, dove investi, fai quell’investimento in capitale, adatti il software ai tuoi processi e via dicendo, e quello diventa un asset che ammortizzi, a dove stiamo andando ora, ovvero spostare tutto nel cloud. Tutti i nostri dati sono nel cloud. Ora si passa da un capex a un opex, e non si tratta solo di una decisione contabile su se siano capex o opex.

Si tratta di un cambiamento di mentalità, perché ora quello che accade è, ad esempio con l’IA, questi grandi fornitori di tecnologia stanno dicendo, “Ehi, abbiamo questa tecnologia di IA che può offrire un valore magnifico alla tua organizzazione.” E questo può essere vero, ma nel processo stiamo prendendo i nostri dati, la nostra proprietà intellettuale all’interno dell’azienda, e li usiamo per addestrare questi modelli di IA che verranno usati da altri concorrenti e altre aziende. Ora, il centro del potere si sta spostando dai clienti ai fornitori, perché ora i fornitori non possiedono i dati, ma possiedono l’IA e la tecnologia che utilizza i tuoi dati per addestrarla, rendendola uno strumento IA migliore da vendere ad altre aziende.

Quindi, questo è importante. È davvero fondamentale riflettere su cosa rappresenta l’IT per noi. È una commodity che vogliamo semplicemente rimuovere dal bilancio, tenerla fuori dalle nostre operazioni perché non vogliamo occuparcene? Forse. Voglio dire, potrebbe andare bene per alcune organizzazioni. Ma hai menzionato Amazon e Spotify. Garantisco che né Amazon né Spotify considerano l’IT come una semplice commodity che qualcun altro potrebbe gestire. È un vantaggio competitivo significativo, e non tutti dobbiamo aspirare a essere Amazon o Spotify, ma possiamo ambire a dire, “Ad esempio, se il nostro punto di forza competitivo è avere una supply chain davvero efficiente, possiamo consegnare prodotti ai clienti più velocemente di chiunque altro, e possiamo personalizzare i nostri prodotti in fretta e farli arrivare prima ai nostri clienti. Ok, quello è il nostro vantaggio competitivo. Ora costruiamo una tecnologia che sia unica per noi affinché quel vantaggio diventi davvero difficile da replicare. Se mi limito ad acquistare una soluzione cloud standard che chiunque può comprare, allora avrò perso il mio vantaggio.”

Quindi, tutto questo movimento verso la standardizzazione dei processi nel cloud, usando i dati per addestrare modelli di IA a beneficio di altri, sta cambiando. Penso che sia una tendenza molto pericolosa che causerà molti rimpianti nelle organizzazioni per anni a venire. Quindi, credo sia importante fermarsi e riflettere. Se vogliamo che l’IT sia un asset strategico che ci differenzia, allora trattiamo il progetto come tale. Ciò probabilmente significa che non adotteremo una tecnologia standard pronta all’uso che sia nel cloud. Forse sceglieremo una soluzione personalizzata più su misura, anche se è una cattiva parola e non si dovrebbe parlare di personalizzazione, di sviluppo custom. Quella potrebbe essere la scelta giusta per te se consideri l’IT come un vantaggio strategico.

Joannes Vermorel: Vantaggio, sì, e vorrei anche sottolineare ancora una volta che molti fornitori hanno incentivi assolutamente terribili. Ancora una volta, la stragrande maggioranza dei fornitori di software per le imprese fa pagare per posto. Quindi, quando fai pagare per posto, non stai affatto cercando di migliorare la produttività. Se riesci a rendere il tuo software meno efficiente o meno produttivo, allora avrai più posti.

Vedi, è—voglio dire, ovviamente, i fornitori di software per le imprese non sono, sai, non sono malvagi. La maggior parte dei dipendenti sono persone buone, proprio come il 90% della popolazione. Non cercano di peggiorare il loro prodotto solo per avere più posti, ma comunque, il potere degli incentivi è estremamente importante.

Questo significa che, per esempio, se esiste un contesto per il fornitore di software che richiede un sacco di persone a operare il software, quelle situazioni saranno… Quando l’amministratore delegato della società di software guarda le proprie vendite, dice, “Oh, guarda, c’è così tanto slancio.” Sì, perché qui, in quest’area, ci serve che tantissime persone interagiscano con il software, e ciò genera il fatturato.

E all’improvviso diventa tutto molto complicato. Vuoi davvero metterti in gioco come fornitore di software se stai facendo pagare per posto in un contesto in cui il tuo prossimo aggiornamento potrebbe forse eliminare il 90% dei tuoi posti? È una domanda davvero, davvero difficile. È una domanda difficile. A proposito, storicamente è già successo ad IBM. IBM faceva pagare per MIPS, milioni di istruzioni al secondo – era quello che facevano negli anni ‘80 e ‘90. E indovina un po’? Quando IBM faceva pagare per MIPS, il loro software diventava via via più lento a ogni generazione, ovviamente.

Eric Kimberling: Sì, voglio dire, stai sollevando un tema davvero – un altro argomento su cui potremmo dedicare un intero episodio, ovvero le aspettative disallineate o gli incentivi disallineati. Sai, se il tuo fornitore di software, il tuo system integrator, e, sai, le tre parti principali, hanno tutti incentivi molto diversi in conflitto, allora diventa difficile superare la situazione.

Conor Doherty: Scusate l’interruzione, ma tengo presente il tempo di Eric. Siete stati molto gentili a restare con noi, quindi io – almeno potremo ritornare su questo e parlare dell’etica delle azioni di tutti. Ma per oggi, passerò a un pensiero conclusivo. Inizio con te, Joannes, con una nota positiva ancora una volta. Che consiglio daresti alle organizzazioni, nonostante tutto ciò di cui abbiamo parlato, oppure tenendo conto di tutto ciò che è stato detto? Che consiglio daresti alle organizzazioni che stanno per iniziare la loro trasformazione digitale?

Joannes Vermorel: Come appassionato di software da quattro decenni – ero un appassionato anche, sai, tempo fa, anche se per lo più dei videogiochi quando ero molto giovane – come appassionato di software per tutta la vita, direi che non credo ci sia mai stato un momento migliore in cui le tecnologie software promettessero così tanto. È davvero incredibile per me – la rivoluzione del deep learning, il suo discendente con gli LLM e via dicendo. È quasi magico, sai, l’idea che puoi avere qualcosa che è in grado di elaborare il linguaggio naturale per fare un’infinità di cose.

È assolutamente incredibile, e quelle tecnologie sono facilmente accessibili. Non sono necessariamente economiche, ma sono facilmente accessibili. Quindi direi che non c’è mai stato un periodo in cui ci si potesse aspettare di più da una trasformazione digitale. Penso che in questo momento, se consideri quella trasformazione digitale, essa abbia la promessa di rendere davvero la tua azienda una realtà completamente diversa che offre molto di più ai tuoi clienti in tanti modi. Può garantire un servizio migliore per i tuoi clienti, operazioni più intelligenti. Chiamalo come vuoi; ha un potenziale assolutamente enorme.

Quindi direi, sogna in grande e poi spendi con attenzione e in modo graduale per cose che non sono come mega progetti a causa del rischio — questo sarebbe il mio messaggio per la trasformazione digitale. Devi metterti in una posizione in cui puoi fallire rapidamente, perché, in qualità di fornitore di software, posso dirti che se chiedi a un cliente, “Puoi darmi una stima davvero pessima di ciò che accadrà nei prossimi sei mesi?” Sei mesi, forse posso farlo. Sì, un anno inizia a essere complicato; due anni sono complicati, complicatissimi, perché potrei avere persone che si alternano. Potrebbe essere, per quanto dirompente, un progetto lungo due anni da gestire, è molto difficile.

Cinque anni—oh cielo, è come se stessimo cercando di progettare la Morte Nera. Quindi, secondo me, sì, la trasformazione digitale ha un potenziale enorme. È eccellente, non è così costosa, quindi dovresti provarci invece di pensare che dobbiamo assicurarci che funzioni. Direi di fare il contrario: fare cose piccole, realizzarle velocemente e fallire rapidamente, in modo che se falliscono, tu possa riconoscere subito che si tratta di un costo sommerso e andare avanti invece di raddoppiare, raddoppiare e raddoppiare, che è esattamente la ricetta per quei fornitori di software aziendale che finiscono per far spendere ai loro clienti dieci volte di più rispetto a quanto inizialmente speso.

Devi essere in grado di dire, “No, ci fermiamo. Abbiamo provato, abbiamo visto, abbiamo finito. Proveremo qualcos’altro perché il mondo è vasto. Abbiamo così tanto potenziale; non dobbiamo assolutamente attenerci al piano originale. Va bene se un’iniziativa fallisce dopo tre mesi. Semplicemente non va bene se fallisce dopo tre anni.”

Eric Kimberling: Dopo aver già speso miliardi o centinaia di milioni di dollari.

Joannes Vermorel: Sì, sì.

Conor Doherty: Beh, Eric, qui è consuetudine dare l’ultima parola agli ospiti, quindi, ancora, la stessa domanda: qualche consiglio da condividere per le persone o le aziende che stanno per iniziare il loro percorso?

Eric Kimberling: Beh, voglio dire, quello è stato un ottimo consiglio che hai appena dato. E aggiungerei forse che, sai, investi in—investi nella gestione del cambiamento. Assicurati di dedicare il tuo tempo alla gestione del cambiamento per rendere meno probabile che tu debba persino fallire in fretta. Ma sono d’accordo, vuoi fallire in fretta, ed è per questo che penso che iniziare in piccolo, iniziare lentamente e poi accelerare sia molto più efficace che partire troppo in fretta e in grande e poi dover rallentare successivamente. Questo crea solo molti problemi di morale, molta incertezza e dubbi all’interno dell’organizzazione.

Quindi, sì, fallisci in fretta, ma investi anche nel cambiamento organizzativo. E l’altra cosa che direi è di prenderti il tempo necessario all’inizio, perché quei primi mesi di un progetto, prima ancora di iniziare ad implementare la tecnologia, sono fondamentali per definire la traiettoria. Voglio dire, stai definendo la visione, i parametri, la direzione del progetto. Quindi assicurati di fare bene quella parte. Se non lo fai, se hai dubbi sulla chiarezza, prenditi il tempo per sistemarla.

Perché più tempo spendi all’inizio per fare bene quella parte, più velocemente avanzerà tutto nel complesso. Infatti, implementerai molto più rapidamente e risparmierai tempo e denaro se rallenti all’inizio. Puoi sempre accelerare in seguito, ma comincia piano. Questo sarebbe il mio ultimo consiglio conclusivo.

Conor Doherty: Non ho altre domande. Grazie mille per il tuo tempo, Eric, molto apprezzato.

Eric Kimberling: Ottima conversazione, anche molto divertente, mi è piaciuta.

Conor Doherty: Quindi, Joannes, non ho altro da dire se non un grandissimo grazie per il tuo tempo, Eric, ancora. Grazie mille anche a te, e grazie a tutti per averci seguito. Ci vediamo alla prossima.