00:00:00 I fallimenti di SAP scatenano questa approfondita analisi
00:02:15 Miliardi persi sull’ERP - solo la punta dell’iceberg
00:06:15 Gli errori di progettazione legacy perseguitano i sistemi moderni
00:10:20 La logica del land grabbing dietro la proliferazione dell’ERP
00:12:26 Applicazioni CRUD e commoditizzazione degli ERP
00:16:30 HANA è stata la svolta strategica di SAP verso l’analisi
00:20:38 Perché i database tabulari falliscono nel reporting
00:26:23 Database a colonne: pro e costi nascosti
00:30:21 Scommettere sul RAM è il rischio che ha fallito
00:34:31 Collisioni di performance nei database ibridi
00:40:41 Il software ibrido fallisce in tutto
00:42:33 Sistema di intelligenza: un terzo paradigma
00:46:59 Gli ERP precoci falsamente pubblicizzati come intelligenti
00:52:33 Perché S/4HANA non può essere tutto contemporaneamente
00:58:43 Il fallimento di Google con CRUD mostra un mismatch culturale
01:05:02 La programmabilità è fondamentale per i sistemi decisionali
01:10:38 Il fallimento economico dell’approccio tutto-in-uno
01:16:30 Perché la modernizzazione dell’ERP è così lenta e costosa
01:22:06 Ottimizzare le decisioni, non solo i processi
01:27:24 Consigli sulla costruzione del proprio livello di record
01:34:13 Open source e il vero costo della tecnologia di base
Riassunto
In una discussione illuminante tra Conor Doherty di Lokad e il CEO Joannes Vermorel, approfondiscono i problemi finanziari associati alle implementazioni software di SAP. Vermorel chiarisce i problemi fondamentali della fusione dei sistemi di record, dei sistemi di report e dei sistemi di intelligenza in una singola soluzione ERP, che porta a inefficienze e conflitti. Mettono in evidenza i costosi fallimenti sperimentati da aziende come DHL e Lidl a causa delle strategie difettose di SAP, in particolare l’integrazione di HANA. Vermorel propugna sistemi specializzati e soluzioni open source come PostgreSQL, che offrono funzionalità robuste a costi inferiori, indirizzando le aziende lontano dalle amalgamazioni software complesse e inefficaci.
Riassunto Esteso
Alla luce delle recenti rivelazioni che mostrano le numerose perdite finanziarie legate all’implementazione del software SAP da parte di grandi aziende, Conor Doherty, Direttore della Comunicazione presso Lokad, si è seduto con Joannes Vermorel, CEO e Fondatore di Lokad, per una discussione approfondita. La loro conversazione, che spazia dalle sfide del design del software aziendale ai rischi delle strategie ambiziose ma difettose di SAP, offre un’analisi ricca e illuminante.
Vermorel spiega le sottili distinzioni nei sistemi software utilizzati dalle aziende: sistemi di registrazione, sistemi di report e sistemi di intelligenza. Il problema fondamentale sorge quando le aziende cercano di amalgamare questi tre sistemi distinti all’interno di un unico pacchetto software, portando inevitabilmente a conflitti e inefficienze. Questo scenario è esemplificato dall’incorporazione da parte di SAP di elementi fondamentalmente incompatibili all’interno delle sue soluzioni ERP, come HANA, con conseguenti significativi ritardi strategici e operativi nel tempo.
Gli esempi di fallimenti legati a SAP sono impressionanti. Come ha ricordato Conor, aziende come DHL, Lidl, Spar e Asda hanno riportato perdite per centinaia di milioni di dollari a causa delle loro implementazioni ERP di SAP. Queste perdite sono solo una frazione della più ampia stagnazione economica sperimentata da queste organizzazioni durante i lunghi periodi dedicati agli aggiornamenti di sistema. Vermorel sottolinea che tali iniziative bloccano gli sforzi di modernizzazione e soffocano altri progressi digitali, inflazionando drasticamente i veri costi di questi progetti.
Il nucleo del problema, sostiene Vermorel, risale alle decisioni fondamentali prese da SAP decenni fa. SAP si è originariamente concentrata sui sistemi di registrazione - essenzialmente sofisticati registri elettronici che miravano a coprire aspetti completi delle operazioni aziendali. Questa strategia di “occupazione territoriale” ha portato a ambiti estesi ma ha anche comportato una commoditizzazione delle operazioni CRUD (Create, Read, Update, Delete). Entro gli anni 2000, si è verificato un passaggio verso i sistemi di report, portando a strumenti analitici sofisticati ma ingombranti.
Una delle scelte critiche fatte da SAP è stata l’integrazione di HANA, un database columnar in-memory progettato per migliorare le capacità analitiche ma non adatto come database fondamentale per le operazioni transazionali. Vermorel dettaglia come questo errore strategico abbia avuto ripercussioni diffuse, rallentando i processi core e creando problemi di performance che hanno richiesto un’eccessiva e costosa sovra-ingegnerizzazione per essere gestiti.
L’intervista tocca il conflitto intrinseco tra le esigenze di progettazione dei diversi sistemi software. I sistemi di registrazione richiedono un rapido e alto livello di elaborazione transazionale, mentre i sistemi di report richiedono ampie capacità di analisi dei dati. Combinare questi con i sistemi di intelligenza, che mirano ad automatizzare le decisioni attraverso la programmabilità, complica ulteriormente l’architettura del software. Questo dilemma è paragonato a cercare di costruire un veicolo che sia contemporaneamente un ottimo aereo e un fantastico battello - un’impresa destinata a risultare in un ibrido mediocre.
Conor menziona il ruolo della simpatia meccanica nella scelta delle soluzioni software - essenzialmente comprendere le caratteristiche intrinseche e i vincoli del software, come le differenze tra database tabulari e columnar. Una conoscenza di base potrebbe aiutare le aziende a evitare decisioni costose.
La nota ottimistica di Vermorel sottolinea la promessa delle soluzioni open-source come PostgreSQL. Egli sostiene l’utilizzo di questi sistemi accessibili e robusti, suggerendo che il loro modesto costo e l’alta funzionalità offrano un percorso valido per evitare i rischi illustrati dagli errori di SAP.
In conclusione, la discussione tra Vermorel e Doherty sottolinea una cautela essenziale: mentre le soluzioni software ambiziose promettono di unificare diverse funzionalità sotto lo stesso tetto, la realtà è che tali integrazioni spesso portano a una complessità e a problemi di performance eccessivi. Le aziende dovrebbero invece considerare sistemi specializzati adatti alle loro esigenze specifiche, beneficiando del ricco panorama delle offerte open-source che offrono un’eccellenza ingegneristica elevata senza i costi esorbitanti associati. La conversazione serve come quadro guida per le aziende per navigare nella loro trasformazione digitale evitando errori storici che si sono dimostrati economicamente dannosi.
Trascrizione Completa
Conor Doherty: Bentornati a Lokad. Alla luce delle recenti notizie che alcune grandi aziende hanno perso ingenti somme di denaro sulle loro implementazioni SAP, Joannes e io abbiamo deciso di sederci e discutere, beh, cosa è andato storto esattamente. Joannes descrive le sfide dietro la progettazione di software aziendale e la sua prospettiva sulle differenze tra sistemi di record, sistemi di report e sistemi di intelligenza. Come sostiene Joannes, quando le aziende cercano di produrre tutti e tre in un unico software, iniziano a emergere problemi.
Ora come sempre, se vi piace ciò che sentite, iscrivetevi al canale YouTube e seguici su LinkedIn. E con questo, vi presento la conversazione di oggi. Quindi Joannes, grazie per esserti unito a me nel Black Lodge. Dovrei preparare il terreno un po’ per te.
Nell’introduzione, ho riconosciuto che uno dei motivi per cui siamo qui è discutere di alcune grandi aziende che hanno perso ingenti somme di denaro. Ora, è una dichiarazione molto ampia. Come siamo davvero arrivati a avere questa conversazione è stato un post che è diventato in qualche modo virale su LinkedIn da Anthony Miller, un amico del canale, dove ha raccolto molte cifre piuttosto impietose relative, in molti casi, a aziende da miliardi di dollari che riportavano centinaia di milioni di dollari di perdite che attribuivano alla loro implementazione SAP.
Quindi, solo per citare o parafrasare, dovrei dire, DHL ha apparenemente perso oltre 370 milioni di dollari cercando di implementare una soluzione SAP e IBM. Lidl in Germania - ora prima che qualcuno mi corregga nei commenti, è Lidl in Irlanda, è Lidl sul continente ma è Lidl in Irlanda - hanno tagliato le perdite dopo aver speso mezzo miliardo di euro. Quindi, hanno interrotto l’implementazione dopo mezzo miliardo di euro.
SPAR, la catena olandese, sosteneva di aver perso 109 milioni di dollari di vendite a causa della loro implementazione SAP. Quindi, una conseguenza dell’implementazione. E ASDA ha segnalato 25,5 milioni di dollari di discrepanze di magazzino tra il loro SAP ERP e il loro WMS. Di nuovo, ce ne sono altri, ma il punto qui è dire che si tratta di oltre un miliardo di dollari o un miliardo di euro di perdite. Quindi, non stiamo parlando di spiccioli qui.
Quindi, arrivo alla domanda: Joannes, cosa non funziona esattamente con queste enormi aziende e le loro implementazioni SAP?
Joannes Vermorel: E ovviamente, il denominatore comune di tutti questi problemi è la scelta del fornitore sbagliato, SAP. Ma, uh, ma anche, penso sfortunatamente, che questi numeri siano solo la punta dell’iceberg. In realtà, la mia osservazione occasionale è che le perdite sono di ordini di grandezza superiori e queste sono solo quelle che le persone riconoscono. Voglio dire, e non riconoscono davvero i costi reali.
Loro, uh, ad esempio, riconoscono solo il fatto che hanno pagato per qualcosa che non ha funzionato. Quello che non riconoscono è che di solito il processo ha richiesto molti anni per molti di quei progetti. In realtà, l’azienda è rimasta ferma nel tempo per mezzo decennio, a volte un decennio, dove non poteva fare altro che concentrarsi sull’aggiornamento dell’ERP.
Quindi, vedete significa che non solo avete sprecato centinaia di milioni, ma in realtà è solo una piccola cosa perché quello che avete effettivamente fatto è mettere in pausa tutta la modernizzazione, tutta la digitalizzazione, tutta la trasformazione in corso che avreste potuto fare altrimenti perché dovevate occuparvi dell’aggiornamento dell’ERP. E ho visto molte, molte volte dove le aziende intraprendono un processo pluriennale dove mettono in pausa tutto per far accadere questa cosa. Il costo è assolutamente gigantesco.
Significa che è ovviamente una testimonianza della qualità di quelle aziende che riescono a sopravvivere a questo processo perché, diciamocelo, ad esempio, nell’industria del software, chiunque metta in pausa lo sviluppo per mezzo decennio sarebbe morto. Voglio dire, sarebbe stato sostituito da cose che sono tre generazioni di tecnologie oltre a loro. Quindi, applausi a quelle aziende che riescono a sopravvivere. Significa che hanno un’assoluta padronanza del loro gioco in modo da poter sopravvivere così a lungo con un processo così disfunzionale.
La realtà è che le prospettive sono assolutamente terribili. E se andiamo oltre questo denominatore comune e vogliamo esaminare la causa radice, perché dare la colpa a SAP non fa luce sul caso, penso che la causa radice sia una serie di errori commessi molto tempo fa, letteralmente decenni fa.
Conor Doherty: Decisioni aziendali o intendi errori software? Quando dici errori, cosa intendi?
Joannes Vermorel: Intendo, errori di progettazione strategica commessi da persone di SAP che risalgono a decenni fa. Quei fallimenti possono essere ricondotti a errori commessi decenni fa. Ed è interessante perché quando si analizzano questi fallimenti, sarà il gioco delle colpe: “L’integratore non era buono” o “La gestione del cambiamento non è stata fatta correttamente nell’azienda” o “Il dipartimento IT dell’azienda non era al livello che avrebbe dovuto essere” o questo o quello o quello o quello. Sapete, scuse scuse scuse.
E in effetti, ogni singolo fallimento sembra unico perché è un pasticcio molto specifico ogni singola volta. Ma di nuovo, quelle non sono spiegazioni soddisfacenti. Penso che se si vuole davvero capire perché sorgono tutti questi problemi, è qualcosa di molto specifico per quei grandi fornitori di software aziendale. Ci sono chiare cause radici che possono essere ricondotte a decisioni prese decenni fa. Ora stiamo solo vedendo le conseguenze dispiegarsi.
Il pubblico potrebbe non rendersi conto, ma quando si gestisce un’azienda di software, si deve convivere con i propri peccati, con i propri errori passati per molto tempo, possibilmente per sempre. Ed è molto strano perché si penserebbe che il software sia completamente mutevole, si può cambiare tutto ciò che si è fatto. La realtà è diversa.
Tornando a differire, di solito quando si tratta di decisioni architettoniche, quando si commettono errori, si può rimanere bloccati con essi indefinitamente. E quegli errori tornano a perseguitarti per sempre, e avvelenano tutto ciò che stai facendo. Le persone vedono i sintomi, tutti i problemi, ma non necessariamente li riconducono alla causa radice, che è spesso così vecchia che le persone non la vedono.
Conor Doherty: Beh, SAP, per inciso, è un’azienda enorme che risale a più di 50 anni fa. Quindi quando parli di cause radici e scelte di progettazione strategica fatte decenni fa, convivere con quegli errori nel 2025, sono affermazioni abbastanza estreme che richiedono prove straordinarie. Puoi darmi un esempio di quale potrebbe essere una scelta di progettazione strategica degli anni ‘70 che sta tormentando un ERP SAP nel 2025?
Joannes Vermorel: Quindi, SAP è iniziata alla fine degli anni ‘70 e sono ciò che descrivo come sistemi di registrazione. È quello che la gente chiama ERP, CRM, WMS, tutti quei pezzi di software, che sono fondamentalmente il corrispettivo elettronico di qualcosa che sta accadendo nell’azienda. Quei sistemi di registrazione, non c’è intelligenza; sono, direi, registri sofisticati. Se torniamo indietro nel tempo, i fornitori che hanno avuto successo sono stati quelli che hanno fatto il maggior numero di acquisizioni.
Cosa intendo per acquisizioni? Se inizi a gestire l’inventario, devi gestire i dipendenti, poi devi gestire gli ordini, poi i pagamenti, poi gli approvvigionamenti, i clienti, i fornitori, i partner, ecc. L’idea è che devi andare e conquistare il territorio di avere una copertura completa - una copertura il più estesa possibile per i tuoi registri. Tornando indietro nel tempo, diciamo negli anni ‘80, questa competizione per acquisire territorio era in corso. La realtà era che per qualsiasi azienda che iniziava ad adottare un fornitore dominante (potrebbe essere SAP, Oracle o IBM), si sarebbe verificato un effetto del vincitore prende tutto all’interno dell’azienda.
Sei un’azienda cliente, utilizzi software da un fornitore, non appena inizi a trattare con questo fornitore, trasferirai praticamente tutto il tuo business a questo fornitore. Perché? Perché all’epoca l’ingegneria del software distribuito era assoluta. Significava che se tutto il software non fosse vissuto nello stesso mainframe, eri fregato. In teoria, potevi fare networking (siamo negli anni ‘80) e alcune banche lo facevano all’epoca, ma era estremamente complicato, estremamente costoso.
Realisticamente, l’unica soluzione economicamente valida per gestire l’inventario e i fornitori e collegare i punti era mettere tutto ciò nello stesso sistema. Quindi, un fornitore per vincere deve coprire tutto. Questo è ciò che alla fine farà avere successo i fornitori - le persone che svilupperanno ciò che viene chiamato ERP e CRM. Quei grandi mega sistemi sono stati quelli che hanno avuto successo, avendo una copertura massiccia. Cosa implica ciò? Significa che devi coprire il maggior territorio possibile e finisci per toccare tutto.
Ora, questo non crea molto incentivo per avere iper-coerenza, iper-integrità. Si tratta davvero di conquistare il maggior territorio possibile il più velocemente possibile. Nel processo, ciò che le grandi entità hanno realizzato è che le app CRUD (Create, Read, Update, Delete) sono beni di consumo completi. Nel processo di fare ciò, l’industria del software ha realizzato che questo processo è un bene di consumo completo. Se vuoi avere un sistema di registrazione, un’app CRUD, è molto semplice.
Hai bisogno di un database relazionale e di un framework per fornire una serie di viste per ogni entità, offrendo un’interfaccia utente per eseguire operazioni CRUD per tutte le entità. Puoi creare un cliente, aggiornare un cliente, eliminare un cliente, ecc. Puoi farlo per clienti, fornitori, fatture, ecc. Molto rapidamente, quei fornitori si sono resi conto che questa cosa è solo un bene di consumo completo. La fase di acquisizione di territorio finisce praticamente negli anni 2000. Entro il 2000, non tutto era coperto - stavano emergendo nuove aree, ad esempio, l’e-commerce.
All’epoca, non c’era; devi aggiungerlo. Ci sono costantemente nuove cose, ma la maggior parte dell’acquisizione di territorio era coperta, il che è un problema. Fornitori come SAP hanno visto che la commoditizzazione stava arrivando molto forte. Quei sistemi di registrazione sono facili e dovrebbero essere sporchi economici - sporchi economici. Quindi, come farai a mantenere i tuoi profitti e margini se stai vendendo una tecnologia che è un bene di consumo completo?
È lì che hanno visto un lato positivo: sistemi di report. Negli anni ‘90, è emersa un’azienda chiamata Business Objects, creando il primo grande successo nella vendita della tecnologia OLAP (Online Analytical Processing) - un sistema di report. Questo è stato un grande successo. Business Objects è stata acquisita nel 2006 o 2007 da SAP. Le persone si resero conto che forse il valore sta più nei sistemi di report. All’epoca, sembrava di lusso.
Chiaramente, a differenza dei record elettronici in cui una volta che hai tutte le informazioni nel database sui tuoi clienti, il tuo valore è un po’ limitato. Dovresti fornire controparti elettroniche per l’attività. Una volta che hai una rappresentazione elettronica soddisfacente dell’attività, non c’è molto da aggiungere. Ci sono solo tante cose che puoi aggiungere per descrivere un prodotto nel tuo database, un cliente, ecc. In definitiva, c’è questa spinta verso l’analisi. SAP si rese conto di questo e decise di puntare tutto su questa seconda fase a partire dal 2010 con HANA.
Questo sarebbe, per me, il nocciolo della maggior parte dei problemi di oggi. Penso che derivi da questa decisione di optare per HANA. Tornando a questa decisione all’epoca, SAP aveva ancora un problema strategico: la dipendenza dai database di terze parti. Negli anni 2000, si basavano principalmente sui database Oracle, un po’ su Microsoft e IBM DB2, ma principalmente Oracle. Questo significava che l’ERP all’epoca, SAP ECC e tutte le loro suite (con molti prodotti e acquisizioni), dipendevano da un database di terze parti.
Questo era un problema perché una grande parte del valore andava a un’altra società di software. A causa della commoditizzazione, competere per un mercato in contrazione era problematico. SAP decise di lanciare il proprio livello di database, chiamato in codice HANA. Vedendo chiaramente che volevano spingere forte in questa direzione analitica, puntarono su un sistema colonna e in-memory. Questa decisione da sola, nel 2010, svelò l’errore.
L’ERP S4 è stato rilasciato solo nel 2015. Quindi una volta che hanno il loro nuovo sistema di database, hanno bisogno di alcuni anni per ricostruire la propria tecnologia ERP su questo nuovo database. Ma se torniamo indietro nel tempo, penso che il nocciolo dell’errore che si sta svelando ora possa essere ricondotto a HANA. Ora dobbiamo capire un po’ di più. È un po’ più complicato, quindi magari ci vorrà un po’ di tempo per spiegare cosa sta succedendo qui.
Per un sistema di registrazione, ciò di cui hai bisogno è un database tabellare, cioè un database tradizionale. Quindi cos’è un database tabellare? È un database che ha tabelle in cui i dati sono organizzati riga per riga. Questo è una cosa che devi tenere presente con i sistemi informatici: la località di riferimento è estremamente importante per le prestazioni. Ciò significa che quando vuoi accedere a una raccolta di dati, se vuoi avere prestazioni, tutti questi dati dovrebbero essere situati in un unico luogo nel sistema, nello stesso posto.
Quindi diciamo che vuoi aggiornare un fornitore. Il fornitore ha molte informazioni: il suo nome, la sua posizione, la sua certificazione, questo, quello. Voglio dire, puoi pensare a tutti gli attributi dell’entità fornitore all’interno del tuo sistema. Sarà una tabella. Ci sarà forse una tabella chiamata “Fornitori”, e questa tabella avrà decine, forse un centinaio, di colonne. Quindi se organizzi il tuo database in modo tabellare, significa che quando scegli un fornitore, visualizzerà il fornitore.
Tutte le informazioni di un determinato fornitore sono in qualche modo collocate nello stesso posto all’interno del tuo sistema. E se vuoi aggiornare, stessa cosa. E se hai una rappresentazione tabellare dei tuoi dati, è molto semplice aggiungere una riga, rimuovere una riga. Di nuovo, queste cose sono piacevolmente collocate. Funziona alla grande. Quindi per i database tabellari, per i sistemi di registrazione, sono semplicemente perfetti.
Ma sono completamente scadenti quando si tratta di analisi. Questo è un problema. Questa è la scadente qualità di quei database tabellari. È il motivo principale per cui gli oggetti aziendali, sai, quelli e tutti quegli strumenti di BI, hanno avuto successo in primo luogo. È perché negli anni ‘90 hanno iniziato a fornire ciò che viene chiamato OLAP, che sono cubi, ipercubi, che vivono accanto al database e che sono molto più comodi per fornire analisi.
E perché è così? Voglio dire, pensaci. Se vuoi guardare, diciamo che hai una tabella che sono ordini, e la tabella ordini ha, diciamo, una colonna che è l’importo espresso, diciamo per semplicità, in dollari. Ma la tabella ordini ha altrimenti come 100 colonne. Ora vuoi calcolare quanto vendite in dollari hai avuto l’anno scorso. La realtà è che se vuoi calcolare questo fatturato dell’anno scorso, che è solo una somma della colonna, sai, degli importi, sarai in grado, se hai un database tabellare, di analizzare praticamente l’intera tabella. Il tuo sistema passerà attraverso ogni singola riga, ma di conseguenza, non sarà in grado di individuare la colonna dell’importo perché è completamente in mezzo a tutto il resto.
Quindi per calcolare questa aggiunta di questa singola colonna, finirai per guardare l’intera tabella, che potrebbe essere centinaia di volte più informazioni rispetto alla singola cifra che desideri per ogni riga, il che rallenta notevolmente il sistema. Ora, c’è una soluzione, ed è organizzare il database lungo un setup colonnare. Quindi cosa significa? Che invece di raggruppare o impacchettare i dati riga per riga, li impacchetti per colonna.
Improvvisamente, se vuoi selezionare una colonna e fare un’operazione come, “Voglio sommare tutto ciò che è in questa colonna”, diventa super veloce perché hai accesso a questa colonna in isolamento. Non hai bisogno dell’ID ordine, dell’ID cliente, dell’ID prodotto e di tutti gli altri campi che troveresti nella tabella ordini. Selezionerai la singola colonna che desideri. Stessa cosa se vuoi fare una selezione per data, sarai in grado di selezionare la colonna della data e applicare il tuo filtro.
Sarà di ordini di grandezza più efficiente. Molto interessante. Quindi, e tra l’altro, questo setup colonnare è storicamente, sai, quando le persone hanno iniziato a fare analisi aziendale, hanno iniziato con ipercubi, quelle tecnologie OLAP. Ma molto rapidamente, alla fine degli anni 2000, le persone si sono rese conto che i database colonnari erano semplicemente migliori. Quindi c’era come una fase in termini di tecnologia in cui gli oggetti aziendali stavano affrontando ipercubi, e la tecnologia si è trasformata molto rapidamente in una versione superiore di quella, che erano i database colonnari.
Ora, i database colonnari sono molto migliori per le analisi. Quindi per tutti quei sistemi di report, è una fantastica notizia. Abbiamo qualcosa di molto migliore per il pubblico. A proposito, un database colonnare potrebbe essere, ad esempio, Spark, un’implementazione open-source che fornisce un database colonnare.
Questa è una scalabilità incredibile da gestire, ed è molto, molto efficiente in termini di prestazioni. Ora, ciò non significa che questa cosa non comporti un compromesso. Il compromesso è che un database colonnare è completamente inutile per un sistema di record. Questo significa, per progettazione, che sarà su due fronti. Primo, se si organizzano i dati in colonne, ogni volta che si vuole aggiornare una riga, si finisce per toccare molte colonne. Bisogna identificare la posizione corretta in ogni colonna, e se si hanno 100 colonne, significa che si avranno 100 posizioni distinte nel sistema da aggiornare.
Mentre in passato, con il database tabellare, si poteva fare un solo aggiornamento; sarebbe stato solo locale. Ma qui, i dati sono organizzati in colonne. Quindi se si vuole aggiornare un record, sarà distribuito su molte colonne. Sarà di ordini di grandezza meno efficiente. Di nuovo, qui non c’è pranzo gratis. O si organizzano i dati come un sistema tabellare, ed è ottimo per i sistemi di record, oppure si fa colonnare, ed è ottimo per i sistemi di report. Non si può avere entrambe le cose.
SAP ha deciso di puntare tutto su HANA, che era un database colonnare. Penso che quella sia stata la decisione da sola che ha segnato la rovina di tutto ciò che stavano facendo come strato fondamentale, che erano i sistemi di record.
Conor Doherty: Ok, solo per intervenire perché è stato coperto molto, è stato buono, grazie. Ma nel caso, per situarmi come qualcuno che potrebbe essere in ascolto ora, potrebbe dire, “State seriamente sostenendo che DHL e Spar e Asda hanno perso, in totale, un miliardo di dollari di inventario o solo denaro cercando di implementare solo a causa di errori analitici colonnari rispetto a tabellari? Questa è la causa radice del problema. È questa una affermazione che viene fatta?”
Joannes Vermorel: In larga misura, sì. Voglio dire…
Conor Doherty: Sostienilo per me.
Joannes Vermorel: Sì, il fatto è che quando si commettono errori architettonici critici, tendono a sfuggire al controllo causando migliaia di effetti collaterali. Non è perché qualcosa è super caotico e complesso che la causa radice è di per sé qualcosa di molto complicato e caotico. Un esempio sarebbe la rotazione della Terra. La Terra rispetto al Sole ha un’inclinazione nel suo asse, che causa un sistema super complicato di stagioni con periodi caldi e freddi, venti e tonnellate di cose che sono solo una conseguenza di questa semplice inclinazione.
Quindi si può avere una causa radice estremamente semplice, ma quando si guardano le conseguenze, sono incredibilmente complesse e varie, eppure si possono ricondurre a qualcosa di molto semplice.
Conor Doherty: Sono d’accordo, ed è un bel esempio astronomico.
Joannes Vermorel: Qui, questo significa che prendendo una decisione positiva per le loro analisi ma dannosa per il loro sistema di record, hanno creato un sistema incredibilmente lento. Qui possiamo anche vedere il tipo di scommessa che SAP ha preso nel 2010. Non hanno solo reso colonnare; l’hanno reso anche in-memory. Questo è stato un altro errore. L’idea di renderlo in-memory significa che hanno detto che tutti i dati vivranno in DRAM, essenzialmente il tipo di RAM che si ha per i server.
Il pensiero dell’epoca era che la DRAM sarebbe diventata incredibilmente economica e molto più veloce in futuro. Le aziende software tendono a dire: “Abbiamo un problema di prestazioni ora, ma se prendiamo le decisioni giuste, il progresso dell’industria hardware annullerà questo problema per noi in futuro.” Credono che se l’hardware di calcolo diventa cento volte più veloce o migliore nella giusta direzione, allora qualsiasi problema di prestazioni che hanno ora potrebbe scomparire entro pochi anni.
Microsoft era nota per fare questo per molto tempo. Rilasciavano software che funzionava a malapena su qualsiasi macchina, poi, dopo alcuni anni, tutto era più veloce e il software funzionava alla perfezione. Il problema è che dal 2010, la RAM non è progredita quasi quanto in un decennio e mezzo. Ha fatto progressi, ma solo un po’ rispetto a tutto il resto, specialmente rispetto ad altre forme di memorizzazione dei dati come gli SSD.
La RAM è rimasta pressoché invariata per quanto riguarda il costo, la velocità, la latenza e tutto il resto, ma i dischi a stato solido (SSD) sono migliorati di un fattore di oltre mille nello stesso periodo. Quindi hanno puntato tutto sulla speranza che questa tecnologia migliorasse di ordini di grandezza, ma non è successo, e molto probabilmente non succederà per molte ragioni. Altre cose stanno progredendo come pazzi nella scienza informatica.
Le schede grafiche utilizzate - le GPU utilizzate per l’IA - stanno progredendo enormemente. Voglio dire, ci sono molte altre aree che stanno progredendo enormemente, ma questa no. E il problema è che il sacrificio che si sta facendo se si utilizza il proprio database rendendolo colonnare per eseguire un sistema di record è che la latenza sarà semplicemente orribile.
Le cose saranno lente praticamente per progetto. E questo era già un problema con il collo di bottiglia del design tabellare. Era già un problema, ma qui lo stai rendendo molto, molto peggiore. Il che significa che come conseguenza di ciò sarai sempre a combattere per mitigare tutti i problemi che sono causati in primo luogo dalla tua architettura errata.
Conor Doherty: Beh, questo presenta la transizione perfetta perché stavo per dire esattamente le stesse parole. Se applichi semplicemente ciò che hai appena descritto - il sistema di record e il sistema di report - il sistema di record, il tuo ERP, in un caso d’uso concreto scansioni i codici a barre e il sistema viene aggiornato in modo da sapere quanto di una cosa hai nel tuo magazzino in un determinato momento o quanto ne hai in negozio. Ok, perfetto. Questo richiede presumibilmente una latenza piuttosto bassa?
Joannes Vermorel: Assolutamente.
Conor Doherty: Ok, perfetto. Ora, qual è la struttura di progettazione per quel sistema di record che o comporta il pericolo o comporta il costo di un buon sistema di report, che è solo per scopi di reportistica aziendale essenzialmente. Dove è il tira e molla? Perché mi stai dicendo che c’è un tira e molla, ma non capisco in termini… Vuoi che il sistema, vuoi che il tuo nucleo razionale sia iper reattivo quando si tratta di scansionare il codice a barre. Quindi scansioni il codice a barre e fa beep, la cosa viene riconosciuta, tutto è a posto. Il codice a barre esiste nel tuo sistema. Tutto. Quindi questo è il beep che ottieni - il sistema riconosce che tutto è registrato. Siamo a posto. Andiamo avanti. Perfetto.
Joannes Vermorel: Ora il problema è che, in primo luogo, se si opta per una configurazione colonnare, questa singola operazione, che è solo riconoscere che hai appena scansionato qualcosa, sarà molto più lenta per definizione perché sarà necessario collegare decine di informazioni che devono collegare i puntini con molte colonne disgiunte nel tuo sistema.
Quindi hai questo come primo ostacolo che rende molto più difficile avere un sistema così reattivo per progettazione perché, di nuovo, i database colonnari sono ottimi per l’analisi su larga scala. Non sono reattivi. Non c’è nulla in quei database che è veramente progettato per basse latenze. Questo non è ciò per cui sono stati progettati. La stessa progettazione è un po’ antagonista a questo.
Ora il problema è aggravato da un’altra cosa, ovvero stai affermando che il tuo livello di database verrà utilizzato come lo stesso identico che stai utilizzando per il tuo sistema di record. Quindi le cose che gestiscono il tuo inventario, i dipendenti che timbrano, tutto dove vuoi una precisione assoluta esattamente. E vuoi anche una reattività estrema quando qualcuno timbra e fa il badge.
Non vuoi che il sistema dica “Dammi 20 secondi mentre capisco se sei un dipendente effettivo e se puoi effettivamente fare il badge oggi.” No! Vuoi che questa cosa sia super reattiva. Badge, beep, subito! Altrimenti tutto rallenta un po’.
Ora il problema è che lo stesso identico sistema perché lo hai progettato come un database colonnare con l’intento esplicito di voler fare analisi. Poi tu - il sistema di record per il sistema di report - sì. Quello che succederà è che le persone faranno report. Dici, “Ok, abbiamo questo sistema che è letteralmente progettato in modo che possiamo fare analisi sofisticate. Facciamo analisi sofisticate!”
Ma qual è la conseguenza delle analisi sofisticate? La conseguenza è che fai operazioni in cui scansioni - dove devi elaborare quantità molto grandi di dati. E questo è completamente antitetico alle basse latenze. Hai questo nucleo di database che è condiviso tra tutti i processi. Deve essere condiviso perché altrimenti non hai integrità. Le persone non hanno la stessa visione di qual è il livello di stock attuale.
Se non hai la stessa visione su qual è il livello di stock, significa che qualcuno sul sito web può ordinare un’unità che non hai perché qualcun altro ha già preso questa unità e ci sono stati ritardi nella propagazione di queste informazioni. Il commercio elettronico crede che ci sia ancora un’unità rimasta quando non ce n’è più. È un bel pasticcio!
Quindi devi avere questa integrità in modo che non finisci con un sacco di problemi stupidi. Ora la tua risorsa di database relazionale è condivisa tra cose molto leggere che devono essere super veloci e cose molto pesanti - i tuoi report in cui dici “Analizza tutti i clienti che hanno effettuato più di tre acquisti l’anno scorso per categoria” e così via.
Quindi hai richieste che sono computazionalmente intensive, che passano attraverso una parte considerevole di tutti i dati che hai. Questo è l’antagonismo. Questo è il punto di fare analisi. L’analisi non riguarda il recupero di questo SKU o di questo cliente. L’analisi riguarda la scansione di ogni singolo cliente per avere statistiche su questo e quello.
Scannerizzerò l’intero mio storico delle vendite degli ultimi anni per analizzare una questione di tendenze. Quindi hai gli stessi sistemi in cui hai molte operazioni molto esose. E di nuovo, come si mitiga il fatto che danneggia completamente le tue latenze?
Voglio dire, la risposta è che devi risolvere il problema con l’hardware. Che tipo di hardware devi risolvere il problema? Beh, devi aggiungere memoria perché hai deciso nel 2010 che sarebbe stato un sistema in memoria colonna. Sfortunatamente!
Se il mondo avesse preso una direzione diversa, se la DRAM fosse diventata mille volte più economica e veloce, quella sarebbe stata la scelta perfetta. Ma non è successo e molto probabilmente non succederà. Voglio dire, questa tecnologia - la DRAM - sta ancora progredendo ma non così velocemente come la maggior parte delle altre tecnologie nell’hardware informatico.
È una delle tecnologie che sta progredendo più lentamente, specialmente sulla latenza dove è rimasta praticamente ferma per quasi due decenni. Ci sono addirittura classi di cose, specialmente sul fronte della latenza, dove non dovresti aspettarti alcun miglioramento a breve.
Ci saranno molti miglioramenti ma non su questo fronte. Quindi le persone che hanno puntato tutto - come giocare a poker e puntare tutto - ma le loro carte non sono affatto buone. Questo è praticamente ciò che è successo nel 2010. E vediamo le conseguenze che si dispiegano in modi molto diversi oggi.
Conor Doherty: Di nuovo, voglio cercare di riassumere il più possibile. Correggimi se sbaglio. Le scelte progettuali che si fanno per eccellere nella prima classe di software - software aziendale che descrivi come sistemi di record - sono antitetiche alle scelte progettuali che faresti se volessi eccellere in un pezzo di software analitico come un sistema di report.
E cercare di fare entrambe le cose - ibridare, come hai detto - cercare di fare entrambe contemporaneamente porta essenzialmente a una lotta dove potresti fare entrambe le cose, ma le farai meno bene di quanto avresti fatto se le avessi fatte individualmente.
Joannes Vermorel: Più o meno, sì. Esattamente. Voglio dire, questo è il problema: non puoi avere qualcosa che sia sia una barca molto buona che un aereo molto buono. È uno o l’altro. Se cerchi di fare entrambe le cose, è possibile, ma sarà una barca scadente e un aereo scadente.
Conor Doherty: Beh, perché di nuovo sono familiare con il blog in cui hai introdotto per la prima volta questo concetto - diventerà un po’ più complicato tra poco. Ma prima di farlo, copriamo il terreno o riassumiamo il terreno che abbiamo coperto. Usi l’analogia della corsa e del sollevamento pesi. Le cose che ti rendono molto bravo - e mi piace perché l’analisi riguarda prendere tutto. Mi è piaciuta l’idea del sollevamento pesi come analogia.
Puoi essere un sollevatore di pesi molto, molto bravo. Se vuoi sollevare 200, 300 o 400 chili da terra, devi essere grande per farlo. È una mossa basata sulla potenza. Correre 100 metri in meno di 10 secondi? Non lo farai se pesi 150 chili; semplicemente non succederà. Quindi puoi essere molto bravo a correre esercizi aerobici, o puoi eccellere e essere di classe mondiale negli esercizi di sollevamento pesi anaerobici. Non puoi essere entrambi, e se cerchi di essere entrambi, non eccelli davvero in nessuno dei due.
Joannes Vermorel: Sì, esattamente. Sì, beh, la cosa è di nuovo, perché sono familiare con il luogo in cui hai introdotto questa prospettiva, c’è effettivamente una terza categoria per le classi di software aziendale. Poiché abbiamo coperto nuovamente i sistemi di registrazione - ERP, che registrano elenchi di dati, unità di stock disponibili - hai i tuoi sistemi di report - strumenti BI essenzialmente per scopi analitici e di presentazione. C’è una terza classe di software di cui non abbiamo ancora parlato.
Conor Doherty: Cos’è?
Joannes Vermorel: Il terzo è il sistema di intelligenza. La cosa interessante è che un sistema di intelligenza, a differenza delle prime due classi, mira a prendere decisioni direttamente. Questo è tutto. La cosa interessante è che se guardi alla storia del software aziendale dall’inizio alla fine degli anni ‘70, tutto il software aziendale è sempre stato, indipendentemente da ciò che facevano effettivamente, commercializzato come sistemi di intelligenza, il che è piuttosto sorprendente.
Quindi non importa se stai vendendo un sistema di intelligenza o meno. Finché stai puntando alle imprese, sarà commercializzato come un sistema di intelligenza - decisioni migliori per te.
Conor Doherty: Sì, ed è molto sorprendente. Guardiamo, ad esempio, il software di gestione degli inventari. In effetti, questa cosa è solo un registro. Conta solo quanto hai in magazzino. Quando prendi qualcosa, decrementa il tuo stock. Quando metti qualcosa, incrementa il magazzino. Questo è tutto. Non fa nulla oltre ad essere un riflesso elettronico del tuo stock.
Joannes Vermorel: Quei prodotti venivano inevitabilmente commercializzati come “Avrai meno rotture di stock e meno sovrastock”, che non ha nulla a che fare con il registro stesso.
Conor Doherty: No, voglio dire, potresti dire che avrai maggiore efficienza nel tenere i conti del tuo inventario. Potresti avere meno errori di natura amministrativa, ma dire che avrai decisioni migliori sull’inventario - perché pensi questo? Il software non lo fa. Ti dice solo cosa hai. Ti permette solo di prendere le tue decisioni, forse in modo leggermente migliore.
Ma è come giocare a scacchi su una scacchiera reale o su una scacchiera elettronica. Certamente, se vuoi tenere traccia di tutte le tue partite passate, la versione elettronica è più conveniente, ma il fatto che sia su un computer non ti renderà un giocatore di scacchi migliore. Molto probabilmente, potrebbe persino essere una distrazione che in realtà ti rende un giocatore di scacchi peggiore.
Non è scontato che le decisioni che prendi con un computer siano automaticamente migliori solo perché stai interagendo con un computer invece di farlo con una penna su carta. Potrebbe succedere, ma non è progettato per farlo logicamente. Oserei addirittura dire che la mia esperienza informale è che quando chiedi alle persone di pensare davvero a qualcosa, uno schermo del computer è una sorta di distrazione per regola.
Direi che se vuoi davvero prendere decisioni migliori, non sono sicuro che uno schermo con una grande quantità di confusione aiuti a concentrarsi e pensare davvero in modo approfondito.
Joannes Vermorel: Questa è una affermazione molto audace. Solo per essere chiari, non stiamo ignorando il valore di un sistema di registrazione. Il punto, per come lo capisco, è di non confondere il tuo sistema di registrazione e le sue capacità con le capacità di un pezzo di software progettato esplicitamente per produrre decisioni.
Per difendere quei primi fornitori di software aziendale, era estremamente confuso. Quello che è molto chiaro per noi ora - quei sistemi di registrazione, app rudimentali, sistemi di report con tutti gli strumenti di business intelligence e analisi moderna, e poi sistemi di intelligenza in cui hai capacità di previsione, capacità di ottimizzazione, con l’idea di automatizzare letteralmente i processi decisionali - questa sorta di classificazione era semplicemente super confusa allora.
Stavano cercando di fare tutte e tre le cose e negli anni ‘70, i primi sistemi di gestione degli inventari venivano commercializzati come “Automatizzeremo direttamente tutte le decisioni sugli inventari”. Venivano commercializzati in questo modo. La comunità si rese conto che era molto facile gestire l’inventario. Gestire nel senso che c’è persino una sfumatura nel termine gestione.
Quando le persone parlavano di gestione degli inventari negli anni ‘70, intendevano tutti i tipi di cose che un manager avrebbe fatto, e un manager non si sarebbe limitato a fare la contabilità. Avrebbe anche preso decisioni sugli inventari. Quindi le persone dicevano che quando pensavano alla gestione degli inventari, pensavano a qualcosa che avrebbe fatto l’intero pacchetto - tenere traccia dell’inventario e prendere tutte le decisioni rilevanti. Si è scoperto che non era così.
Quindi abbiamo suddiviso il dominio in gestione degli inventari, ottimizzazione degli inventari - l’ottimizzazione appartiene al sistema di intelligenza. Ma in quel momento, era super confuso. Lo stesso vale per l’analisi - puoi mettere le cose in mostra, ma le persone non si erano rese conto di quanto sarebbero cresciuti i database e di tutte le sfide che avresti dovuto affrontare per produrre statistiche da essi.
Avere statistiche era già possibile fin dall’inizio. Quei sistemi di solito giravano durante la notte, passando una volta attraverso l’intero database per raccogliere statistiche. Quindi era in qualche modo possibile, anche con un database tabellare, potevi avere batch notturni che raccoglievano le statistiche che cercavi, ma era molto scomodo perché era molto lento.
Dovevi preparare la tua logica in anticipo e una volta che avevi la tua logica, dovevi aspettare fino al batch notturno per eseguirlo. Ti rendevi conto di avere un errore nel tuo codice solo il giorno successivo. Operativamente, era un incubo. Era possibile, ma la quantità di attrito era semplicemente esagerata.
Ecco perché strumenti come Business Objects hanno sviluppato essenzialmente tecnologie OLAP con ipercubi, dove potevi avere in pochi secondi alcune analisi. Questo è stato un vero game changer perché improvvisamente non dovevi passare, diciamo, implementare qualcosa e aspettare fino a domani per vedere se avevi commesso un errore. Potevi farlo a una velocità 100 volte superiore rispetto a prima.
Conor Doherty: Prima, hai menzionato S4/HANA, che è stato rilasciato nel 2015. Al momento della registrazione di questa conversazione, è quasi vecchio di dieci anni - credo che siano passati dieci anni esatti, due giorni fa. Ora, dopo aver esaminato il materiale di marketing ad esso associato, in particolare utilizzando la tua classificazione, è stato presentato come avente tutte le capacità di un sistema di registrazione, un sistema di report e, attraverso la sua presa di decisioni guidata dall’IA, un sistema di intelligenza. Quindi hai affrontato i problemi creati cercando di combinare sistemi di registrazione e sistemi di…
Joannes Vermorel: Alcune analisi che, direi, sono state un vero game changer perché improvvisamente non dovevi passare, sai, implementare qualcosa e aspettare fino a domani per vedere se avevamo commesso un errore. Solo per ribadire, potevi farlo a una velocità 100 volte superiore rispetto a prima.
Conor Doherty: Beh, di nuovo, hai menzionato SAP S/4HANA, rilasciato nel 2015. In realtà, al momento della registrazione di questa conversazione, sono quasi passati 10 anni - credo, sono passati 10 anni esatti due giorni fa. Ora, dopo aver esaminato il materiale di marketing associato a ciò, in particolare utilizzando la tua classificazione, è stato essenzialmente presentato come avente tutte le capacità di un sistema di registrazione, un sistema di report e, attraverso la sua presa di decisioni guidata dall’IA - un sistema di intelligenza. Quindi hai già affrontato i problemi quando si cercano di combinare sistemi di registrazione e sistemi di report contemporaneamente. Cosa succede quando si cercano di fare tutti e tre quei sistemi sotto lo stesso tetto?
Joannes Vermorel: Sì, voglio dire, qui stiamo cercando di essere un treno, una barca e un aereo contemporaneamente, quindi è ancora peggio. Sai, è come entrare nel territorio di Frankenstein dove sarà davvero brutto. La realtà è che tutto è un po’ contro di te come fornitore di software se cerchi di fare tutti e tre. Fermati un attimo per capire esattamente cosa implica.
Un sistema di registrazione, tipicamente si addebita per operatore, per posto, per utente. È il modo in cui si vendono questo tipo di cose oggi; sarà una metrica molto tipica. Se stai facendo un sistema di intelligenza, questo non ha senso perché in pratica elimini gli utenti. Oh sì, quindi è questa la tua intenzione - vuoi prendere belle decisioni. Quindi ovviamente, più sei bravo, meno utenti hai. Alla fine, avresti solo una manciata di utenti nell’azienda cliente solo per supervisionare le tue decisioni e basta. Quindi, se stai addebitando per utente, questo non funzionerà; hai un antagonismo così forte in termini di incentivi. Ma ovviamente, è solo un dettaglio; ci sono molti altri problemi.
Il problema è che il tipo di ingegneri del software di cui hai bisogno non è lo stesso. A proposito, penso che una società, quella società di software, che ha avuto un grosso problema dall’opposto, fosse Google. Google è stato pioniere in cose che erano molto nel campo dei sistemi di intelligenza. Qual è stata la decisione intelligente presa da Google all’epoca? Quella era la ricerca; ecco la mia query, identifica cosa è più rilevante tra un miliardo di siti web. È una decisione che viene presa, e deve essere fatta in modo molto intelligente. Google ha fatto fortuna facendo in modo che quelle decisioni fossero prese estremamente bene - almeno meglio della concorrenza. Hanno costruito un’intera forza lavoro sull’idea che avrebbero avuto ingegneri molto intelligenti che affrontavano problemi molto difficili perché prendere decisioni, la caratteristica è che sono quasi molto difficili.
Ecco perché vuoi delegarle a un computer. Se non fossero difficili, non qualificherebbero nemmeno come decisioni. Se qualcosa è solo una questione di semplice aritmetica, diresti “Ok, è solo un calcolo di base, non c’è niente da vedere qui, passa oltre.” Google ha assunto tonnellate di ingegneri capaci per realizzare quei sistemi sofisticati. Quando si è trattato di sviluppare sistemi di registrazione, che sono banali, noiosi e ripetitivi, beh, hanno fallito.
Se guardi alla storia di Google, ogni cosa banale è stata gettata dalla finestra. Avevano Google Reader, un lettore di blog, che è stato ampiamente adottato. Era semplice, un’app grezza, ma un’app grezza non è sufficiente per Google, quindi l’hanno gettata via. Avevano dozzine di prodotti simili in cui se è un’app grezza - grezza nel senso di Creare, Leggere, Aggiornare, Eliminare - l’hanno rilasciata ma non sono riusciti a mantenerla perché era al di sotto di loro.
Questo è un vero problema quando hai l’intera azienda orientata allo sviluppo di sistemi di intelligenza: la tua forza lavoro ingegneristica non è propensa a fare lavori noiosi e ripetitivi. Al contrario, se hai vissuto per decenni facendo sistemi di registrazione, la tua forza lavoro è abituata a creare migliaia di schermate, riconoscendo “Ok, questo software avrà bisogno di 5.000 o 20.000 funzionalità distinte, tutte individualmente molto facili senza alcuna sfida”, ma devono comunque essere fatte.
In termini di forza lavoro ingegneristica e cultura, è completamente diverso. La mia percezione è che SAP si è ritrovata con una forza lavoro orientata a questa mentalità di acquisizione di terreni - cerchiamo di avere un miliardo di ingegneri che possano creare un miliardo di schermate e un miliardo di funzionalità, tutte estremamente semplici individualmente. Poi cercano di passare a sistemi di intelligenza, e hanno fallito in modo molto grave.
Un’area in cui puoi vedere persone brave nei sistemi di intelligenza è che raggiungono progressi tecnologici, e ciò si traduce in progetti open-source. Google, ad esempio, potrebbe non essere riuscito a mantenere app grezze, ma è riuscito a rilasciare pezzi preziosi di tecnologie open-source, molto intricate e difficili da ingegnerizzare grazie alla loro forza lavoro talentuosa. Se guardi a SAP, non sono sicuro di poter menzionare nemmeno un singolo progetto open-source di interesse emerso da SAP a titolo di confronto.
Conor Doherty: Beh, mi viene in mente che abbiamo passato parecchio tempo a delineare la struttura dei sistemi di registrazione e dei sistemi di report, ma non abbiamo effettivamente affrontato quali sarebbero esattamente le scelte di progettazione architettonica strategica - le scelte di progettazione architettonica strategica - per un sistema di intelligenza e perché questo sarebbe incompatibile con le altre due architetture. Ad esempio, Lokad è un sistema di decisioni, un sistema di intelligenza; cosa c’è nella sua struttura che significa che cercare di conciliare ciò con un sistema di registrazione sarebbe problematico, per dirla in modo leggero?
Joannes Vermorel: Direi che un sistema di intelligenza per le sue fondamenta ha alcune somiglianze con un sistema di report. Vuoi questa rappresentazione colonnare; questo ha molto senso per l’analisi. Ma poi, ciò che desideri da un sistema di intelligenza è la programmabilità molto rapida. Se vuoi la flessibilità di ingegnerizzare un processo decisionale, hai bisogno di qualcosa di estremamente espressivo. A proposito, ecco perché i fogli Excel vengono frequentemente utilizzati per supportare i processi decisionali; con Excel, ottieni un linguaggio di programmazione, che è molto importante.
Le formule di Excel possono diventare arbitrariamente complesse, e se sei sofisticato, puoi persino programmare tramite VBA o Python. Excel è programmabile, ed è per questo che viene frequentemente utilizzato come strumento per supportare i sistemi di intelligenza. Hai bisogno di programmabilità, che è un gioco completamente diverso rispetto ai sistemi di report dove dovrebbe essere accessibile a tutti. Ti trovi nel territorio del WYSIWYG (What You See Is What You Get); hai interfacce sofisticate, che è il mondo dei sistemi di report.
Conor Doherty: Mi viene anche in mente che c’è una prospettiva economica qui che non abbiamo ancora toccato. E di nuovo, sei un uomo di economia, un uomo di Thomas Sowell.
Mi viene in mente che che sia o meno in termini di software una decisione intelligente cercare di acquistare una soluzione tre in uno in cui hai il tuo sistema di registrazione, report e intelligenza tutti insieme. Possiamo lasciare da parte questo. Non c’è un argomento economico che direbbe che come insieme di compromessi, potrebbe essere più conveniente acquistare essenzialmente un unico software che almeno afferma di poter fare tutte e tre le cose piuttosto che tre abbonamenti separati a tre software separati, tre problemi separati, dover addestrare tutti a usare tre cose separate?
Joannes Vermorel: Sì, voglio dire, questa è letteralmente la storia dell’F-35. Stai parlando di questo caccia americano che sarà l’aereo più costoso di sempre. Il problema è che queste cose non sono lineari.
Se dici, “Voglio che il mio aereo sia super efficace nel combattimento ravvicinato, super efficace nelle operazioni a lungo raggio e stealthy, e possa decollare verticalmente”, finisci con qualcosa in cui ogni volta che aggiungi una caratteristica, raddoppi il prezzo dell’intera cosa.
Quindi alla fine, ti ritrovi con un aereo che costa il prezzo tipico di forse dieci altri aerei—uno per operazioni a lungo raggio, uno per il combattimento tattico con un altro aereo, uno per essere stealthy, uno per il decollo verticale. Non è necessario avere tutto questo, ecc. ecc. Quindi, vedi, non è lineare. Non puoi avere tutte quelle cose in un’unica configurazione.
Ora, potresti dire che se SAP avesse deciso di avere tre sistemi completamente indipendenti—uno che si occupa del sistema di registrazione, uno che si occupa del sistema di report, il terzo che si occupa del sistema di intelligenza—e metti muri cinesi tra tutte quelle divisioni e operano in modo indipendente, potrebbe aver funzionato. Ma non è quello che è stato fatto.
La tentazione era troppo forte per unire tutto, comprese le soluzioni di terze parti acquisite. Il mix è semplicemente tossico. Prendi prodotti che si mescolano molto male, e ottieni qualcosa di disfunzionale. Penso che sia quello che stiamo vedendo adesso.
Tornando alla timeline, abbiamo avuto HANA nel 2010. Ci sono voluti cinque anni per implementare S/4 su quella base. La maggior parte di questi fallimenti sono letteralmente stati una decade in preparazione. Stiamo guardando a cose che hanno richiesto un decennio per dispiegarsi.
Stiamo guardando a fallimenti di HANA che stanno diventando visibili pubblicamente. È solo la punta dell’iceberg. I costi opportunità di molte aziende sono semplicemente folli perché ci vogliono così tanti anni per fare l’aggiornamento. Stiamo parlando di aggiornamenti di cinque anni o più, che è semplicemente assurdo.
È folle. Guarda il fatto che ChatGPT e l’IA generativa non esistevano cinque anni fa. Sarai così in ritardo nella battaglia. Inoltre, sono state prese decisioni molto sbagliate, come puntare tutto sui sistemi in-memory, il che significa spendere troppo sull’infrastruttura.
Se hai tonnellate di hardware, molto più di quanto dovresti avere, significa che hai bisogno di più amministratori di sistema, più persone in IT per gestire tutto questo. Tutto diventa incredibilmente complesso. Non è solo più complesso ma anche più lento. Queste cose si sommano. È molto più costoso, più lento, hai bisogno di più persone, e fa crescere ancora di più il costo opportunità.
Poi le persone diventano spaventate nel livello di gestione perché c’è così tanto in gioco. Rallenta ulteriormente il processo. È come un circolo vizioso. I problemi stanno diventando visibili. Le aziende fanno del loro meglio per assicurarsi che gli errori interni non diventino di dominio pubblico perché non è una buona pubblicità. Non vuoi pubblicizzare la tua incompetenza. Se puoi gestire tutto dietro porte chiuse, è molto meglio.
Pensa a quanto estremo deve essere il problema per finire per divulgare tutto quel disordine al pubblico. Quasi tutte le situazioni, a meno che l’azienda non sia quotata in borsa e sia contro il muro e debba divulgare le cose perché altrimenti sarebbe considerato frode, non verranno divulgate.
Conor Doherty: Beh, hai menzionato il costo opportunità un paio di volte. Hai menzionato il costo opportunità di essere trascinati in un’implementazione. Improvvisamente, sei bloccato in quel processo, impedendoti di passare a qualcos’altro. Ha anche il costo crescente associato alle persone che lo mantengono.
C’è effettivamente un’altra dimensione a questo, e ho scritto qui “perfezionabilità”. In termini di costo opportunità, se prendessi tutte e tre quelle classi di software singolarmente, e teoricamente sono al meglio quando tenuti separati perché hai un sistema di record separato, un sistema di report separato e un sistema di intelligenza separato.
Cerchi di perfezionare ognuno. C’è un limite superiore a quanto perfetto possa essere un sistema di record. Una volta che hai il 100% accuratezza, è tutto lì. Ad esempio, quanti bicchieri ci sono sul tavolo? Ce ne sono due. Questo è tutto. Non puoi renderlo migliore di così.
Una volta che hai una latenza di 50 millisecondi, è trascurabile; le persone non se ne accorgono più. Un sistema di report—quanto può essere bello un dashboard? Possiamo discutere di estetica, ma c’è un limite superiore su quanto tempo e denaro vuoi investire prima di ottenere rendimenti decrescenti.
Un sistema di intelligenza, come hai detto, coinvolge decisioni. Nella filosofia di Lokad, questo significa considerare il ritorno sull’investimento per ogni decisione presa. Teoricamente, mi viene in mente che non esista un punto di perfezione in cui puoi dire, “Questa è la migliore decisione che potrei mai prendere.”
Non è necessariamente perfezionabile. Puoi continuamente migliorare un algoritmo per prendere decisioni migliori. Mi sbaglio?
Joannes Vermorel: Quindi, no, ma dobbiamo anche dissipare un’idea sbagliata. I matematici direbbero, “Oh, ma una volta che raggiungi l’ottimale, sei il migliore.” Sai, per definizione, una volta che hai l’ottimale, non può essere reso migliore. E per qualsiasi, direi, enigma matematico dato, se prendi un enigma matematico e dici, “Questo è, questo è un enigma,” allora puoi avere la soluzione ottimale per questo enigma.
Ma dove è sbagliato pensare così in ambito aziendale è che la scelta dell’enigma è molto arbitraria. Sai, puoi decidere, “Okay, forse ho ciò che è ottimale per questo framework, ma posso reinventare il mio stesso business e quindi avrò un nuovo framework che mi dà ancora rendimenti più alti.” Quindi, le opzioni che hai non sono statiche. Decidi cosa sei disposto a fare, e tra le cose che sei disposto a fare, potrebbe esserci un ottimale, ma fondamentalmente, le tue possibilità sono infinite.
Non c’è—l’unico limite superiore, per come la vedo io, è l’ingegno umano stesso. Quindi, dici, “Il mio ottimale è privo di significato perché l’ottimale è entro limiti formali.” Dove dico, “Posso decidere solo entro, sai, traccio una linea nella sabbia, dico che posso guardare solo in questa area e dire, okay, entro questa area che ho delimitato nella sabbia, sì, il mio ottimale potrebbe essere quello, forse posso persino dimostrarlo matematicamente.”
Ma la realtà è che è solo una linea tracciata nella sabbia. Puoi andare dove vuoi. Quindi, sì, in definitiva, quando si pensa in termini di decisioni aziendali, non c’è limite oltre l’intelligenza e l’ingegno delle persone che lavoreranno sul caso.
Ora, credo che l’industria del software abbia capito questo molto presto. Sai, è per questo che, fin dagli anni ‘70, tutti i fornitori spingevano per benefici espressi in termini di decisioni migliori. Facevano letteralmente pubblicità a un sistema di intelligenza perché si rendevano conto che il problema di avere una rappresentazione elettronica del proprio inventario era finito. Una volta fatto correttamente, cosa avresti fatto?
Si è scoperto che le persone passavano attraverso fasi. Prima c’erano interfacce testuali, poi interfacce grafiche come con il desktop—il desktop, la generazione di clienti pesanti degli anni ‘90. Oggi hai app web e ora app mobili. Quindi, si è scoperto che anche a livello di interfaccia utente c’erano una serie di transizioni.
Anche se la sfida era finita, si è scoperto che le aziende di software erano comunque impegnate solo nell’aggiornamento dal terminale testuale all’interfaccia grafica all’app web e ora all’app mobile. Ma la cosa è che era molto chiaro per tutti che questa cosa si sarebbe conclusa in qualche modo, nel senso che non sarebbe cresciuta indefinitamente fino a diventare qualcosa di estremamente grande.
Ecco perché, molto presto, molti fornitori, inclusa SAP, si sono impegnati a contrapporsi a quelle decisioni, anche se il loro software in pratica non aveva nulla a che fare con la generazione di decisioni migliori.
Conor Doherty: Beh, mi viene in mente che abbiamo parlato molto di teoria, e questo è positivo. Beh, teoria mescolata con un po’ di pratica qui, ma certamente, voglio cercare di renderla un po’ più pratica. Voglio formularti la domanda in questo modo: All’inizio dell’episodio, ho menzionato DHL, Asda, Spar. C’erano altri esempi dal post di Anthony Miller.
Se fossi in una stanza oggi, se fossi in sala riunioni con i decision maker, i grandi capi, i grandi giocatori, e ti dicessero, “Ok Joannes, cosa dovremmo fare dopo?” Abbiamo provato questo, questo non ha funzionato. Quali sarebbero i tuoi consigli?
Joannes Vermorel: Il mio consiglio è molto semplice. I sistemi di registrazione sono stati completamente commoditizzati più di un decennio fa, infatti, più di un decennio fa. Quindi, procediamo passo dopo passo. Il tuo database sarà, diciamo, PostgreSQL. È open source, è eccellente.
Questa era la cosa nel 2010 quando SAP disse, “Abbiamo avuto così tanti problemi, vediamo Oracle come una minaccia strategica.” Quello che non si sono resi conto è che Oracle era insignificante. Il vero sfidante era in realtà open source.
Quindi, il database relazionale che ha vinto oggi sono effettivamente i database open source. I database relazionali sono ora una completa merce al punto che i prodotti migliori sono progetti open source, e PostgreSQL è un miglio avanti rispetto a Oracle e ai privati.
Quindi, eccoci in una situazione in cui un grande fornitore, SAP, che voleva contenere un altro fornitore, Oracle, ha finito per sviluppare una tecnologia che alla fine risulta essere inferiore a un prodotto open source—che è solo PostgreSQL.
E come faccio a sapere che è inferiore? Voglio dire, basta guardare su Hacker News o discutere su cosa stanno facendo le startup al giorno d’oggi. Ho auditato un numero a tre cifre di startup. Non ho mai visto una startup utilizzare un database relazionale non open source nell’ultimo decennio. Mai.
Utilizzerebbero solo database open source. Non ho mai visto una startup utilizzare, ad esempio, Oracle Database. Mai. Quindi, questo ti dà il sentimento che le persone che conoscono la tecnologia, che si occupano di tecnologia, non fanno questa scelta. Prima di tutto, direi a questa sala di dirigenti, “Per il livello del database, è necessario scegliere una delle eccellenti opzioni open source che sono sul mercato.”
Questo può essere PostgreSQL. Queste soluzioni sono eccellenti e se non lo fai, la perdita di opportunità è enorme perché ciò che ottieni se scegli uno di quei database è che in cima a ciò, hai letteralmente più di un milione di ingegneri del software che sono già competenti su quelle tecnologie rispetto alle tecnologie firewall private e oscure che sono molto più difficili da gestire. Questo era il primo problema.
Poi, di cosa hai bisogno in cima? Hai essenzialmente bisogno di un framework per implementare un’app grezza sopra il database. Ci sono tonnellate di quei framework e di nuovo, sono disponibili in open source. Questo sarebbe Django se sei in Python, sarebbe il framework MVC in ASP.NET per Microsoft, che è anche open source. La lista continua. Questi framework esistono per tutte le principali pile—Python, Java, .NET.
Poiché è completamente commoditizzato, o scegli per il tuo sistema di record un fornitore che è già open source—esistono—o semplicemente lo crei tu stesso e non è nemmeno così costoso. La cosa è che quando ti ritrovi con un progetto quinquennale per fare un aggiornamento ERP, saresti molto meglio a implementare il tuo pezzo di sostituzione pezzo per pezzo.
In sei mesi, potresti avere una serie di moduli che vengono già aggiornati e sostituiti se lo fai internamente o con l’aiuto di un’azienda informatica. Di nuovo, la cosa bella di avere quei sistemi di record completamente commoditizzati è che è estremamente semplice trovare persone che possano farlo. È estremamente semplice esternalizzare queste cose—è anche estremamente semplice farlo internamente se lo desideri.
Il livello è molto basso; è molto economico. Quando guardi tutte le aziende tecnologicamente avanzate di questo mondo—le Zalando di questo mondo—hanno sviluppato il proprio ERP; stanno bene così. Se guardi Amazon, stanno facendo lo stesso; JD.com sta facendo lo stesso. Tutte le persone che sono native digitali hanno visto quella come una soluzione ovvia per il sistema di record.
I record sono completamente commoditizzati. Alla fine, non è difficile, voglio dire, quei prodotti non dovrebbero certamente essere costosi. Se sono costosi, allora il tuo piano B dovrebbe essere, “Ok, sai, lo farò da solo.” Se chiedi a un pittore di fare un quadro per una parete della tua casa e ti dicono che costerà 2 milioni di euro.
Sai, sono quattro metri quadrati, ma sai, se non posso fare di meglio, diresti, “Ok, lo farò da solo.” Sai, se è l’unica opzione, lo farei da solo. Sì, preferirei non fare la pittura, ma sai, non stiamo parlando di inviare razzi nello spazio. Stiamo parlando di qualcosa che è abbastanza semplice comunque.
Conor Doherty: Bene, questo, di nuovo, perché prendo appunti copiosi, come puoi vedere. Ma la domanda successiva che volevo fare era, avendo delineato le tre classi e di nuovo sei di nuovo in quella stanza con i dirigenti, e il nostro potenziale pregiudizio è chiaro, come sai. Lokad è un fornitore di per sé. In termini di costi per ciascuna di queste classi, perché di nuovo, hai commentato più volte negli ultimi due o tre minuti su come, “Guarda, voglio dire, potresti fondamentalmente farlo da solo.”
Voglio dire, se sei tecnologicamente esperto, potresti e sei digitalmente - il termine usato era “digitalmente nativo”, potresti progettare il tuo sistema di record. Ok, beh, allora dovrebbe presumibilmente costare meno di un sistema di report e un sistema di intelligenza o come fai - come allocare il budget in tal senso?
Joannes Vermorel: Voglio dire, chiaramente, i sistemi di record sono molto più semplici rispetto al resto. Sai, di nuovo, sono stati i primi. La tecnologia è completamente commoditizzata. Il software open source fornisce tutti i pezzi di cui hai bisogno. Sviluppare un’app grezza è un esempio lampante di cosa sono gli ambienti di sviluppo integrati.
Quindi, gli strumenti sono eccellenti, il framework è eccellente e gli strumenti sono eccellenti. Hai tonnellate di ingegneri che hanno una produttività enorme, e ancora meglio con LLMs oggigiorno. Questo è il genere di cosa in cui l’IA generativa è fantastica quando si tratta di scrivere tonnellate di codice non intelligente. Quegli strumenti sono super bravi a farlo.
Conor Doherty: Quindi 20 miliardi di dollari, questo è quello che dovremmo addebitare.
Joannes Vermorel: Sì, quindi dovrebbe essere relativamente, voglio dire, dovrebbe essere abbastanza economico di nuovo per le aziende come base. Se finisci per pagare più di un decimo di quello che hai pagato per sistemi simili 10 anni fa, è una truffa. Sai, quello dovrebbe essere il tuo punto di riferimento. Quindi dovresti cercare, “Lo faremo di nuovo, ma con un decimo del budget.” E questo non è nemmeno esagerato.
Penso che considerando l’evoluzione della tecnologia, sia un punto di partenza. Sono abbastanza sicuro che se dovessi impazzire, aggressivo - diciamo che Elon Musk si occupa del caso - sarebbe, “Lo farò per 100 volte più economico.” Ma direi che il tuo prossimo progetto ERP dovrebbe costare un decimo di quanto hai speso 10 anni fa. Penso che sia un punto di riferimento ragionevole, almeno per i sistemi di record.
Per il sistema di report, la tecnologia è piuttosto confezionata. Quindi il problema è che di solito finisce per essere molto costoso perché l’azienda vuole semplicemente un miliardo di report. Il costo è l’implementazione, su misura, di un numero illimitato di report - un numero folle di report.
Quindi, quando hai un sistema di report, a un certo punto le persone direbbero, “Oh, ma mi piacerebbe avere alcuni report che sono pronti all’uso, modelli preconfezionati.” E poi il fornitore direbbe, “Sì, nessun problema, quanti ne vuoi?” E poi elencano, e finisci con migliaia di report. Se fai così, allora diventa incredibilmente costoso solo perché ne stai chiedendo così tanti.
Quindi qui, dovrebbe essere piuttosto economico perché la tecnologia è piuttosto confezionata, ma più dei sistemi di record. È più difficile, quindi è il genere di cosa in cui non consiglierei di fare da soli. Ma di nuovo, con tecnologie open source come Spark, non è così difficile. Anche se è più difficile dei sistemi di record.
Qui, penso che se vuoi mantenere il budget ridotto, devi mantenere sotto controllo le tue richieste. C’è questa tentazione, specialmente nelle grandi aziende, di richiedere un elenco infinito di report che nessuno consumerà mai. Risulta essere super costoso perché tutte quelle persone devono guardare quei numeri di tanto in tanto, e non ha molto senso.
Quindi mantienilo breve e concentrato, e il costo non sarà molto elevato. Dovrebbe essere effettivamente molto inferiore rispetto al costo del tuo ERP di base di 10 anni fa. Ho detto che il nuovo ERP dovrebbe essere quasi un decimo di quello. Il sistema di report dovrebbe essere una frazione di questo costo, non più del 20% del costo di questo ERP di prossima generazione.
Di questo stiamo parlando, qualcosa di molto piccolo. In definitiva, i report non dovrebbero costare milioni o decine di milioni per riportare statistiche descrittive di base sulla tua attività. Non ha senso. La tecnologia è progredita abbastanza da rendere tutto molto economico.
Conor Doherty: Quando hai proposto per la prima volta la categorizzazione delle tre classi o la classificazione dei tre tipi di software aziendale—Tu—Non riesco a ricordare l’esatto rapporto, ma era qualcosa come il 90% del tuo budget IT dovrebbe essere destinato ai sistemi di intelligenza.
Joannes Vermorel: La divisione che ho proposto era del 20% per l’ERP, del 5% per i sistemi di intelligenza e del 75% per—scusa, del 20% per i sistemi di record, del 5% per i sistemi di report e del 75% per i sistemi di intelligenza. Questo è ciò che suggerisco come euristica per la quasi totalità delle aziende.
Al contrario, ciò che sta accadendo oggi è il 75% per l’ERP, il 20% per l’intelligenza aziendale o i sistemi di report e solo il 5% per i sistemi di intelligenza. Dico che questi numeri sono sbagliati. Dovremmo scambiarli. Perché dovresti spendere la maggior parte dei tuoi soldi sui sistemi di intelligenza?
Ovviamente, Lokad è un sistema di intelligenza, quindi il pubblico dovrebbe spendere molti soldi. Ma la realtà è che c’è un ritorno sull’investimento esatto. È lì che puoi avere un grande ritorno se le decisioni sono fatte correttamente. I sistemi di report sono principalmente finalizzati a garantire che non ci siano problemi.
Si tratta di guardare indietro per vedere se sei conforme ai tuoi processi, se sei sulla buona strada. Ma fondamentalmente, nessuna azienda è mai diventata di successo guardando solo indietro. Questo è il problema dei sistemi di report. Stai guardando nel retrovisore.
Se vuoi vincere una gara, non la vinci guardando nel retrovisore. A un certo punto, devi guardare avanti.
Conor Doherty: Mi viene in mente che in realtà ho un laptop davanti a me, e questo ha il Wi-Fi. Il blog a cui facevo riferimento si chiama in realtà “Le tre classi di software aziendale”. Era di giugno dell’anno scorso.
Solo per chiarire i numeri, hai ricordato correttamente come le aziende, la quasi totalità delle aziende, dividono tipicamente le loro spese—Il loro budget IT è del 75% per i sistemi di record, e hai messo scherzosamente “sbagliato” tra parentesi dopo. Il 20% per i sistemi di report, anche “sbagliato”, e il 5% per i sistemi di intelligenza, con “completamente sbagliato” alla fine di quello.
Invertiti il 75% per i sistemi di intelligenza, cinque per i sistemi di report e 20 per i sistemi di record. Ora, uh, consiglio vivamente di leggere il blog. È molto buono.
Ora, uh, ultima domanda prima di iniziare a concludere, ma mi viene in mente. È un punto che hai già menzionato prima e nei tuoi corsi, e l’ho menzionato alcune volte in conversazioni qui: il ruolo della simpatia meccanica. E non dobbiamo parlarne per molto tempo, ma mi rendo conto che una conoscenza di base, diciamo, di quali sono i parametri richiesti o le scelte progettuali architetturali necessarie per eccellere nello strumento che stai cercando di acquistare?
Se sei abbastanza familiare con questo argomento, puoi almeno capire se “Questo potrebbe non essere per me”. Quindi, anche solo la differenza tra database colonnari e tabulari - se capisci bene cosa usa questo sistema e cosa voglio da quel sistema? Questo potrebbe guidarti a riconsiderare immediatamente una scelta potenzialmente costosa.
Joannes Vermorel: Sì. E ancora una volta, se torniamo agli errori che SAP ha commesso nel 2010… Voglio dire, HANA è stata rilasciata nel 2010, quindi probabilmente stavano già lavorando su questo da alcuni anni. E all’epoca, sospetto che sembrasse una buona idea, sai, sembrava, “Ok, supponiamo che quelle latenze che abbiamo all’interno dei sistemi informatici miglioreranno, continueranno a migliorare, che la memoria diventerà sempre più economica.”
Perché di nuovo, se guardiamo a quale sia la grande differenza tra il 2010 e, diciamo, uh, l’anno, uh, 15 anni prima, sai, 1995. Durante quei 15 anni, la memoria era diventata radicalmente più economica e radicalmente più abbondante. Ricordo che all’epoca, nel 1995, ricordo che il primo computer che ho usato, Windows 95, aveva circa 8 megabyte di memoria.
E poi, nel 2010, credo che fosse, all’epoca, Windows 7 o qualcosa del genere. Sospetto che all’epoca avessi 8 gigabyte, sai, quindi era cresciuto di mille volte in questo periodo di tempo. E la latenza era stata divisa per circa un fattore 50 o qualcosa del genere.
Quindi se fosse continuato su questa strada, sarebbe stato incredibile. Significherebbe che, sai, avevo 8 GB sul mio computer nel 2010. Se 15 anni dopo fosse migliorato allo stesso modo, avrei avuto 8 terabyte sul mio computer oggi. Questo non è quello che ho, ovviamente, sul mio computer. Nessuno ha 8 terabyte sul proprio computer.
Ma vedi che se la tecnologia fosse progredita come aveva fatto nei 15 anni precedenti, quello sarebbe stato ciò che le persone avrebbero avuto. E se avessimo avuto anche una simile riduzione della latenza, il problema è che la velocità della luce è un tale problema, sai. La fisica non gioca a tuo favore. Hai questa velocità della luce che è un po’ sul tuo cammino.
Ma comunque, penso che abbiano commesso questo tragico errore. E da lì, così tante cose dovevano essere sovraingegnerizzate perché questo è come il peccato originale. A causa di ciò, dovevi fare così tanti aggiustamenti solo per… Quando hai un problema di progettazione massiccio come quello, puoi cercare di risolverlo con il nastro adesivo. Puoi farlo, ma tutto sarà goffo.
E quindi quando ti trovi di fronte a problemi di prestazioni, puoi risolverli aggiungendo hardware. Sì, ovviamente puoi iniziare comprando hardware super costoso, sarebbe il primo passo. Ma poi puoi sovraingegnerizzare come pazzi alcune cose in modo che non siano troppo disfunzionali. Perché fondamentalmente, con abbastanza ingegneria, puoi mitigare alcuni di quei problemi.
Ma comunque, SAP vuole coprire tutto, con l’ambizione che stavo descrivendo. Vuoi essere il sistema di record per una cosa, ma vogliono essere il sistema di record per tutto. Il che significa che l’area di superficie in cui puoi avere problemi di prestazioni solo a causa di questa scelta è assolutamente gigantesca.
E credo che quello che stiamo vedendo sia solo, sai, in rallentamento, le cose implodono in rallentamento. È quello che stiamo vedendo. Ci vuole molto tempo. Ci sono voluti cinque anni per rilasciare un ERP su HANA, quello è S/4. E poi ci sono voluti anni per vendere l’ERP alla loro prima azienda.
Perché di nuovo, quando vuoi vendere software enterprise, non chiudi l’affare in sei mesi; spesso ci vogliono diversi anni. Quindi ci vogliono come un ciclo di mezzo decennio per implementare. E forse una volta che hai impiegato mezzo decennio, quello è il tuo piano per l’aggiornamento.
È pazzesco. Ma la realtà è che inizi a fallire perché non ci vogliono mezzo decennio, ci vuole un decennio intero. Quindi stiamo solo assistendo a fallimenti causati da decisioni sbagliate prese molto tempo fa. E stiamo risalendo indietro nei decenni passati. Penso che vedremo quei problemi continuare a emergere, ma non è nuovo. Riflette solo errori che sono stati fatti molto tempo fa.
E ora, l’unica cosa che possiamo davvero suggerire è non ripetere errori antichi. Ma la cosa folle è che quegli errori sono stati fatti così tanto tempo fa che le persone di SAP… intendo errori di SAP, e le persone che li hanno adottati pensando che fosse giusto.
E la cosa interessante è che quegli errori sono stati fatti così tanto tempo fa che le persone potrebbero pensare, “Oh, ma oggigiorno dovrebbe essere giusto.” Hanno messo insieme le cose. Hanno messo insieme le loro menti. Questo è risolto. Perché ovviamente, come fornitore, se dovessi proporre un prodotto del genere, direi, “Caro potenziale cliente, stia tranquillo che abbiamo imparato dai nostri errori. Quelle cose sono state corrette. Quegli errori, abbiamo imparato così tanto. Non accadranno di nuovo.”
Direi, non proprio, perché il problema è ancora al centro del tuo tech. HANA è ancora al centro di tutte le offerte SAP. Finché è… Sì, sei fregato. Devi disfare tutto quello per iniziare eventualmente ad entrare in territori più sani.
Oggi, a meno che non cambino rotta e rimuovano HANA, passino a PostgreSQL o qualsiasi altra cosa open source, e poi suddividano la loro offerta in modo che possano avere app snelle che siano strettamente disaccoppiate. Integrare le cose su Internet è piuttosto facile oggigiorno, quindi potrebbero avere un design super modulare.
A meno che non inizino a fare questo, i peccati originali sono ancora lì; l’ambizione di essere il sistema di tutto più il motore sbagliato al centro del sistema.
Conor Doherty: Beh, per cercare di concludere su una nota positiva, ci sono consigli costruttivi che condividi con le persone in modo che possano forse evitare, tra virgolette, le mine vaganti che alcune di queste enormi aziende hanno creato?
Joannes Vermorel: Voglio dire, il vero punto di vista positivo, ed è qui che mi rende molto triste quando vedo quegli errori, è che la comunità open source ha consegnato qualcosa di incredibilmente grande. PostgreSQL è una meraviglia di ingegneria. Questo è open source. Questo è magia.
Viviamo in un’epoca in cui, letteralmente per il prezzo, non è esattamente gratuito - naturalmente devi pagare per la tua connessione Internet - ma per un prezzo incredibilmente basso, puoi avere sistemi incredibilmente ben progettati o pezzi di ingegneria che rappresentano centinaia di anni di alcuni dei più brillanti ingegneri del nostro secolo. Questo è incredibile, e puoi averlo gratuitamente. Quindi, questa è la mia opinione.
