Modularizzazione nella Supply Chain

00:00:03 Introduzione alla modularizzazione nell’IT e nelle supply chain.
00:00:26 Modularità nella supply chain fisica.
00:02:31 Strutture monolitiche dei primi sistemi IT.
00:04:08 Contesto IT dei sistemi monolitici.
00:05:31 Impatto di Internet sul design modulare del software.
00:08:02 Problemi nei sistemi software monolitici.
00:08:48 Inefficienze dei sistemi monolitici.
00:11:16 Transizione verso sistemi modulari: esempi.
00:13:34 Fallimenti di sistema nelle applicazioni modulari.
00:14:34 Ridondanza, uptime nei sistemi modulari.
00:16:00 Affidabilità dei grandi sistemi, fallimenti dei progetti software.
00:16:50 Esempio di transizione fallita del software di Lidl.
00:18:09 Concetto di “fail fast” nei progetti software.
00:19:30 Gestione delle sovrapposizioni, importanza del software “glue”.
00:22:46 Evitare disastri software.

Riassunto

Nell’episodio di Lokad TV, Joannes Vermorel, il fondatore di Lokad, discute dell’importanza della modularizzazione nell’infrastruttura IT aziendale, facendo un confronto con l’adattabilità delle supply chain. Fa riferimento ai sistemi IT monolitici degli anni ‘70 e ‘80, caratterizzati dalla loro inflessibilità dovuta alle limitazioni tecnologiche. Anche con il passaggio verso sistemi in rete a seguito dell’emergere di Internet, sottolinea la sfida continua per le aziende di modularizzare i loro sistemi IT. Vermorel propone l’Architettura Orientata ai Servizi (SOA) come possibile soluzione, sottolineando la necessità di servizi più piccoli e ben definiti. Mette in guardia contro l’affrontare progetti su larga scala e sostiene un approccio “fail fast”, enfatizzando l’importanza della gestione del rischio e del recupero rapido in caso di fallimenti.

Riassunto Esteso

Nell’episodio attuale di Lokad TV, l’ospite Kieran Chandler coinvolge Joannes Vermorel, il fondatore di Lokad, in una discussione sulla modularizzazione nell’infrastruttura IT aziendale. Vermorel illustra il concetto di modularizzazione, tracciando parallelismi principalmente con le supply chain nel mondo fisico, che considera come le creazioni più modulari dell’umanità.

Utilizza gli esempi di camion, pallet e container per chiarire i suoi punti sulla modularità. Vermorel sottolinea la modularità intrinseca delle supply chain fisiche evidenziando l’applicabilità universale dei codici a barre, che possono essere attaccati praticamente a qualsiasi cosa.

Sebbene le supply chain fisiche mostrino una chiara modularità, Vermorel osserva che le infrastrutture IT aziendali spesso mancano di una simile flessibilità. Risale questa mancanza di modularità alle prime fasi dello sviluppo IT all’interno delle aziende negli anni ‘70 e ‘80, quando le prime implementazioni IT e i sistemi ERP sono stati progettati come strutture autonome e monolitiche a causa delle limitazioni tecnologiche dell’epoca.

Vermorel identifica un ‘monolite’ in termini IT come un’applicazione unificata che non può essere suddivisa in parti più piccole. Spiega come questo approccio monolitico contrasti con la modularità osservata nelle supply chain fisiche, dove vari componenti possono essere combinati o separati secondo necessità.

Nonostante la loro complessità, Vermorel spiega che i primi mainframe erano intrinsecamente coerenti poiché funzionavano come un’unica unità con tutte le operazioni centralizzate. Sottolinea come questa forma di progettazione del sistema sembri superata per la generazione attuale abituata a sistemi distribuiti e applicazioni basate su rete, segnando un significativo cambiamento nello sviluppo dell’infrastruttura IT nel corso degli anni.

Vermorel sottolinea che il panorama ha iniziato a cambiare con l’avvento di Internet alla fine degli anni ‘90, portando alla progettazione di software con parti isolate collegate da una rete. Tuttavia, osserva che molte aziende ancora faticano con la modularizzazione, nonostante il valore dei sistemi IT modulari sia ben compreso in teoria.

Spiega come molti fornitori abbiano adattato queste vecchie architetture monolitiche ai modelli cloud e Software as a Service (SaaS), ottenendo sistemi che offrono un miglioramento della manutenzione ma non aumentano la modularità. Afferma che questa mancanza di modularità impedisce alle aziende di isolare e modificare specifiche funzionalità.

Per superare questo problema, Vermorel propone un’Architettura Orientata ai Servizi (SOA), un approccio che suddivide le capacità in “pezzi” più piccoli e ben definiti. Fa riferimento ad Amazon come esempio di un’azienda che ha abbracciato con successo questo approccio modulare fin dall’inizio.

Egli sostiene un’architettura orientata ai servizi con API che consentono di esportare e sfruttare i dati tra diverse divisioni di un’azienda. Nonostante riconosca che un approccio decentralizzato presenta potenzialmente più punti di fallimento rispetto a un sistema monolitico, Vermorel sostiene che queste sfide possono essere mitigate attraverso la ridondanza e l’ingegneria di alta qualità.

Vermorel stima che tra un terzo e la metà di tutti i progetti IT delle supply chain falliscano. Fa riferimento al caso di Lidl in Germania, che ha perso mezzo miliardo di euro in una transizione SAP fallita. Sostiene che il passaggio da piccoli fornitori a grandi fornitori riduce solo leggermente i tassi di fallimento, ma non li elimina.

Riguardo alla gestione di più applicazioni, Vermorel suggerisce di scegliere applicazioni con un campo di applicazione limitato per ridurre al minimo le sovrapposizioni e sconsiglia l’acquisto di grandi framework dai fornitori. Per gestire efficacemente più app, afferma che le aziende dovrebbero sviluppare un “collante” interno che leghi queste applicazioni insieme, facilitato da un’architettura orientata ai servizi.

Infine, Vermorel condivide consigli su come prevenire disastri come la fallita transizione SAP di Lidl. Sottolinea l’importanza di pensare in termini di gestione del rischio e di adottare un approccio “fallire velocemente”. Sconsiglia il pensiero illusorio nella gestione dei progetti e sottolinea l’importanza di pianificare per possibili fallimenti e trovare modi per riprendersi rapidamente.

Trascrizione completa

Kieran Chandler: Ciao e bentornati a un altro episodio di Lokad TV. Questa settimana parleremo di modularizzazione, il processo di suddivisione dei processi informatici della nostra azienda da un sistema autonomo a una serie di altri sottoprogrammi o addirittura app. Come sempre, sono qui con Joannes Vermorel. Quale parte dei processi aziendali stiamo cercando di rendere più modulare oggi?

Joannes Vermorel: Oggi ci stiamo concentrando soprattutto sull’infrastruttura IT e sul panorama applicativo della vostra azienda. La modularizzazione è interessante. Quando si pensa al mondo fisico, è evidente che le supply chain sono incredibilmente modulari. Sono probabilmente le cose più modulari mai inventate dall’umanità. Con modulare, intendo che se si desidera trasportare merci su strada, si possono utilizzare camion. I camion sono incredibilmente modulari perché si può mettere praticamente qualsiasi cosa che non superi la capacità di un camion, e un camion può guidare su qualsiasi strada, andando da qualsiasi luogo a qualsiasi altro luogo. Se hai bisogno di camion aggiuntivi, potresti utilizzare praticamente qualsiasi tipo di camion, quasi, e possono aggiungere capacità di trasporto alla tua supply chain.

Lo stesso vale per i pallet e i container. Si può mettere praticamente qualsiasi cosa su un pallet o in un container purché non superi la capacità. Un container è estremamente modulare. Puoi spostarlo da una nave da carico a un camion. Tutti questi pezzi sono incredibilmente modulari. Puoi mettere un codice a barre su praticamente qualsiasi cosa che non sia troppo piccola. È un’invenzione incredibilmente moderna. Se hai qualcosa come un diamante, probabilmente lo metteresti in una scatola e poi metteresti il codice a barre sopra la scatola. Puoi combinare tutti questi elementi semplici a tuo piacimento, in modo quasi infinito. È molto simile a Lego; parti semplici che puoi combinare in modi incredibilmente vari. Questa è la supply chain fisica, che è incredibilmente modulare.

Tuttavia, la cosa interessante è che quando passiamo al mondo IT, entriamo in una prospettiva completamente diversa e dove spesso la modularizzazione viene persa. Penso che l’origine di ciò risalga ai primi anni ‘70 o ‘80, quando le aziende hanno iniziato ad avere i loro primi sistemi informatici e le prime implementazioni ERP.

Kieran Chandler: Quindi quello che stai dicendo è che quelle prime implementazioni, quei primi sistemi IT, perché erano molto un approccio singolare, è ancora quello che stiamo usando oggi. È quello che stai dicendo?

Joannes Vermorel: Sì, infatti. Quando si pensa al software degli anni ‘70, ‘80 o anche dei primi anni ‘90, fare qualsiasi cosa tramite la rete era come la scienza dei razzi. Era possibile, ma era un incubo ingegneristico. Era molto più facile dire che prendiamo una grande macchina, idealmente un mainframe IBM dell’epoca, e mettiamo tutta la logica su questa macchina. Poi, tutti utilizzano un terminale collegato a questa macchina, e tutta la logica viene eseguita in un monolite su questa macchina.

Kieran Chandler: Quindi cosa intendi per monolite?

Joannes Vermorel: Con monolite intendo un’app che è un tutt’uno. Non può essere smontata. Deve essere insieme o non è nulla.

Kieran Chandler: Mi spiace, sono un po’ un millennial, quindi questa idea potrebbe precedermi un po’. Ma in sostanza, stiamo dicendo che tutto è collegato a una singola macchina, giusto? E poi ci stiamo tutti collegando e stiamo tutti lavorando da lì?

Joannes Vermorel: Esattamente. I mainframe erano cose relativamente complesse dal punto di vista hardware, quindi anche se era una sola macchina.

Kieran Chandler: Stiamo principalmente parlando di ERP, cioè sistemi di gestione delle risorse aziendali. Questi sistemi sono tipicamente progettati per essere estensibili, consentendo l’aggiunta di funzionalità e capacità extra. Tuttavia, non sono modulari, il che significa che non è possibile separare tali funzionalità per mantenerle completamente isolate.

Joannes Vermorel: La cosa interessante è che ciò che è davvero cambiato è probabilmente stato Internet. Non mi riferisco all’invenzione di Internet, ma al fatto che alla fine degli anni ‘90, con l’Internet che diventava molto popolare, le persone hanno iniziato a pensare a come progettare software in modo che si prendano le parti in isolamento, con la rete in mezzo. In questo modo, il flusso di lavoro non è un incubo ingegneristico. Prima di questo, se non sapevi come costruire un sistema software complesso composto da molte parti, avere una rete in mezzo era un incubo ingegneristico. Questa conoscenza, cultura e strumenti sono emersi principalmente come sottoprodotto dell’adozione di Internet da parte del pubblico in generale.

Kieran Chandler: Internet esiste da molto tempo ormai, quindi perché stiamo ancora parlando di modularizzazione? Perché questi software continuano a comportarsi in questo modo singolare?

Joannes Vermorel: Al momento, la mia diagnosi è che quando prendi un’azienda media che gestisce una supply chain complessa o multinazionale con molte sedi, tutto ciò che è fisico è incredibilmente modulare. Tuttavia, quando iniziamo a guardare l’IT, è completamente monolitico. Credo che le aziende e il mercato nel suo complesso abbiano ancora difficoltà a comprendere il valore di avere qualcosa di estremamente modulare in termini di IT. Fisicamente, è piuttosto ovvio, e le supply chain stanno ancora migliorando la loro modularità. Tuttavia, in termini di panorama delle applicazioni, è più astratto, più difficile percepire la modularità come tale.

Molti fornitori hanno preso vecchie architetture monolitiche, le hanno leggermente aggiornate verso SaaS e il cloud, ma hanno solo copiato e incollato. È fondamentalmente lo stesso tipo di architettura che avevi in un mainframe IBM negli anni ‘90, in cui hai solo deciso che invece di avere una macchina nella sede della tua azienda che esegue il tutto, lo delega a un fornitore di software che opera come SaaS. Ma se il fornitore di SaaS ha solo un monolite che viene eseguito su una macchina che è lontana dalla tua sede, con solo un po’ di networking e un’interfaccia utente web in mezzo, non aggiunge nulla per quanto riguarda la modernizzazione. Rende solo più facile la manutenzione. Ma quando si desidera separare le funzionalità, ci si trova ancora di fronte a un monolite in cui questo tipo di capacità non può accadere.

Kieran Chandler: Qual è il problema di questo approccio monolitico? Come sta influenzando le aziende nel mondo reale?

Joannes Vermorel: Immagina l’equivalente fisico della mancanza di modularità. Immagina che nella tua supply chain, ogni volta che vuoi cambiare un camion, devi cambiarli tutti. Ad esempio, se passi da un camion all’altro, hai bisogno di un diverso tipo di carburante. Quindi, tutte le tue stazioni di servizio dovrebbero essere cambiate, il che significa che hai serbatoi che contengono carburante dove hai bisogno di un secondo tipo di carburante. Sarebbe immenso.

Il dolore, vedi, è paragonabile alla situazione nel software. Quando manca la modernizzazione, è come se cambi una parte, devi cambiarle tutte. Se cambi un camion, devi cambiare tutto il tuo parco veicoli. Immagina se cambi gli scaffali di un magazzino e dovresti cambiare tutti gli scaffali di tutti gli altri magazzini, altrimenti non sono compatibili. Poi ti rendi conto, ok, forse posso decidere di aggiornare il mio parco veicoli verso camion elettrici, ma sarà una mossa strategica massiccia ed è molto complicato. Preferiresti comunque avere qualcosa di relativamente modulare in cui puoi far coesistere elegantemente camion elettrici e camion a combustione per un lungo periodo di tempo. Quando manca la modernizzazione, significa che non puoi avere questo tipo di coesistenza. Non puoi cambiare alcune parti della tua supply chain senza cambiare tutto.

La prova aneddotica più frequente di questa mancanza di modernizzazione è che per le aziende spostarsi da un magazzino all’altro fisicamente potrebbe richiedere un giorno, in cui sposti le cose che si trovano in un magazzino dagli scaffali del magazzino A agli scaffali del magazzino B. Ma migrare il software che era collegato al magazzino A in modo che tutto sappia che tutte le cose sono nel sistema che gestisce il magazzino B richiederebbe circa sei mesi.

Kieran Chandler: È interessante. Come fanno le grandi aziende a fare questo se esistono su questo tipo di sistema monolitico? Come migrano verso un sistema più modulare?

Joannes Vermorel: Penso che torneremo a parlare di una delle aziende che abbiamo menzionato praticamente in ogni episodio, come Amazon. Non sono gli unici ad aver adottato un approccio estremamente modulare. In Germania, Zalando, puoi seguire sui blog, ha ora completamente adottato un approccio molto modulare e la parola chiave in IT per questo quando si vuole avere questa modularità è probabilmente Architettura Orientata ai Servizi, SOA.

L’Architettura Orientata ai Servizi significa fondamentalmente che si desidera isolare le capacità in blocchi che sono essi stessi come piccoli monoliti, ma molto più piccoli, e che sono molto ben definiti per fare una cosa e farla bene. E si collegano tutte queste cose attraverso la tua Architettura Orientata ai Servizi, il che significa che ogni singolo servizio, nel senso di un’app che fa una cosa e la fa bene, espone API in modo che possa essere collegato al tuo paesaggio di applicazioni molto facilmente. È progettato per essere facilmente collegabile in modo programmabile a qualsiasi paesaggio di applicazioni arbitrario senza fare quasi alcuna ipotesi su quali siano le altre parti del paesaggio di applicazioni.

Jeff Bezos di Amazon ha pubblicato una memo molto famosa, credo nel 2002, in cui a tutti i suoi team ha detto che ogni divisione deve avere un’architettura orientata ai servizi con API, in modo che i dati che hai nel tuo silos possano essere esportati per essere sfruttati in qualsiasi altra divisione dell’azienda e possiamo interagire in modo programmabile con ciò che stai costruendo.

Kieran Chandler: Il problema che vedo in questo è che ti stai affidando a molte app più piccole, programmi più piccoli, aziende più piccole in definitiva. Non introduce questo molti più punti di rottura? Mentre se si ha un approccio più monolitico, si ha un’azienda grande e solida, un grande sistema ERP che funzionerà sempre e si ha più fiducia in esso.

Joannes Vermorel: È vero, e in certa misura questo è uno dei problemi di un sistema distribuito. Se l’hardware fallisce l'1% delle volte, allora significa se hai un mainframe.

Kieran Chandler: Hai detto che il software può avere problemi tre volte l’anno. Se hai 10 app ognuna con una probabilità dell'1% di essere inattiva in un determinato giorno, significa che circa ogni 10 giorni qualcosa è inattivo nella tua rete. È sicuramente una sfida. Quali soluzioni suggeriresti per questa situazione?

Joannes Vermorel: La ridondanza è la prima cosa che mi viene in mente, ma mi piacerebbe discutere le implicazioni in termini di elaborazione distribuita, e forse poi possiamo parlare di aziende piccole rispetto a grandi e della disparità tra i fornitori. Da un punto di vista dell’elaborazione distribuita, l’obiettivo è garantire che ogni singolo blocco sia altamente ridondante. Questa è l’essenza del cloud computing. Si desidera avere un software fortemente ridondante in modo che il tempo di attività sia molto elevato.

La buona notizia è che perché le tue app sono più piccole e semplici, è molto più facile ottenere un tempo di attività molto elevato con un’app semplice e piccola rispetto a un’app molto complessa. Ci sono molti servizi componenti su Internet che sono letteralmente sempre attivi. Ad esempio, Google Mail è letteralmente sempre attivo. Il sito web di Yahoo è praticamente sempre attivo. Anche Facebook è sempre attivo. Quindi, è possibile progettare queste proprietà “sempre attive” per le tue app, che affrontano l’affidabilità del tuo sistema nel suo complesso.

Kieran Chandler: Cosa ne dici di passare da un grande fornitore a molti piccoli fornitori?

Joannes Vermorel: La realtà è che i tassi di fallimento nel software sono elevati. Le persone non si rendono conto che forse la metà delle volte, le iniziative software falliscono. La mia stima sarebbe che tra un terzo e la metà di tutti i progetti IT della supply chain falliscono per aziende di quasi qualsiasi dimensione. Qualche settimana fa, Lidl in Germania ha praticamente sprecato mezzo miliardo di euro in una transizione SAP fallita. È stato un progetto di sette anni che è finito in un fallimento, e alla fine hanno rinunciato. Ma non è l’unico esempio; questo accade abbastanza frequentemente.

I grandi fornitori probabilmente hanno un tasso di successo migliore, ma se parliamo di cifre indicative, stiamo passando da un piccolo fornitore con un tasso di fallimento del 50%, che è piuttosto alto, a un grande fornitore con un tasso di fallimento del 30%. Quindi, quando passi da una piccola a una grande azienda, il tuo rischio diminuisce leggermente, ma solo un po’.

Se opti per un approccio altamente modulare, sì, avrai molte cose che falliranno, ma avrai l’opportunità di riprovare e ripetere fino a ottenere successo. Ogni componente ha la possibilità di fallire, ma poiché lo scopo è più semplice, l’app stessa è più piccola, puoi fallire rapidamente e riprovare.

La cosa con l’approccio di Lidl è che sono abbastanza sicuro che inizialmente non stavano pianificando una migrazione di sette anni. Probabilmente era una migrazione di due anni che si è trasformata in tre, poi quattro, e così via perché stavano fallendo, ripetendo e fallendo di nuovo. Sette anni dopo, hanno deciso di rinunciare, probabilmente perché tutti avevano perso ogni speranza che il progetto avesse successo.

Kieran Chandler: Quindi, se concordiamo sul fatto che queste app, una volta trovata quella giusta e magari iterata un po’, possono essere affidabili… Sembra che funzionino e sembrano svolgere lo stesso lavoro di un sistema più grande. Cosa ne dici dell’intersezione tra queste app? Perché molte volte, un’app potrebbe fare qualcos’altro bene e potrebbe esserci un po’ di sovrapposizione e conflitto all’interno di quel sistema. Come gestisci tutto ciò?

Joannes Vermorel: Innanzitutto, quando scegli la composizione del tuo paesaggio applicativo, vuoi davvero scegliere app con un campo di applicazione ristretto. Questo approccio va completamente contro ciò che fanno la maggior parte delle richieste di proposte (RFP). Quando le aziende cercano di acquisire un pezzo di software, spesso fanno un RFP e vogliono tutto: tutte le funzionalità, tutte le campanelle e i fischietti. Ma questo è l’opposto di ciò che dovresti cercare. Vuoi qualcosa di estremamente limitato, in modo da minimizzare le sovrapposizioni.

Se stai acquistando grandi framework, è una ricetta per avere sovrapposizioni. I fornitori enterprise sono interessati a venderti grandi framework perché possono estenderli con molte funzionalità. Ti vendono qualcosa e poi ti venderanno gli add-on in cima ad esso. Quindi, direi alle persone che gestiscono grandi supply chain di stare molto attente quando gli viene venduta una piattaforma.

Una piattaforma è buona, ma due piattaforme possono essere un incubo. Non appena hai diversi fornitori che ti vendono piattaforme, ti ritroverai con un mare di sovrapposizioni. La soluzione è scegliere attentamente la composizione dei tuoi ingredienti.

Per quanto riguarda la “colla”, l’approccio è che è qualcosa che di solito vuoi sviluppare internamente. Questo potrebbe andare contro l’intuizione del perché vorresti sviluppare qualsiasi tipo di software in-house. La risposta è che se sei un’azienda di una certa dimensione, il tuo paesaggio applicativo è completamente unico per te.

Anche se usi tutte le app standard, avrai bisogno di più app. Non c’è modo che tu possa avere un ERP al giorno d’oggi che possa gestire email, videoconferenze e così via. Non puoi inserire ogni singola funzionalità di software di cui hai bisogno in un’unica app. Probabilmente userai Microsoft Excel come tutti gli altri, quindi avrai bisogno di un posto dove archiviare i file e così via.

Non è realistico dire che abbiamo un unico pezzo di software. Qualsiasi azienda di dimensioni significative sarà comunque una collezione di software. La ricetta esatta, cioè l’elenco di software che letteralmente gestisce la tua azienda, sarà completamente unica per te comunque. Nessun’altra azienda è organizzata esattamente come te.

Kieran Chandler: È completamente unica, è il tuo DNA. Puoi avere questa colla che implementi internamente. Questo è il punto chiave dell’architettura orientata ai servizi, rendere questa colla semplice e snella da implementare, in modo che tu possa avere un team IT molto snello che richiede sforzi minimi. Per creare questo software personalizzato che unisce tutto insieme. Quindi, per concludere, se sono un CEO, come posso evitare un altro disastro di tipo Lidl?

Joannes Vermorel: Prima di tutto, penso che sia essenziale pensare al rischio anziché minimizzare il rischio. Il disastro di tipo Lidl è stato causato da persone che dicevano: “Non vogliamo correre alcun rischio”, e quindi si rivolgono al più grande fornitore disponibile e cercano di avere un prodotto che faccia tutto. Fondamentalmente, è l’approccio in cui diciamo che vogliamo qualcosa che sia corretto per design e vogliamo implementare qualcosa che aggiorni l’intera azienda in una volta sola. Questo è il peggior tipo di approccio in termini di gestione del rischio.

Devi pensare completamente all’opposto, cioè “Come posso avere qualcosa che fallirà rapidamente se deve fallire?” Vedi, il problema del rischio è che quando hai questo progetto massiccio, non sai per molto tempo se hai fallito o no. Quello che vuoi è avere qualcosa che fallisca rapidamente, dove sai se hai fallito e il fallimento è su piccola scala. E se hai bisogno di una sostituzione, hai uno scopo gestibile e lo fai con molti piccoli pezzi.

Quindi, pensa a come evitare il rischio. Sto dicendo che passando da un grande fornitore a un piccolo fornitore, potresti aumentare il rischio dal 50% di probabilità di fallimento al 50%. Alla fine, se una probabilità del 30% di fallimento significa che la tua azienda fallisce o che la supply chain si blocca, non è un rischio che puoi correre. Quindi, devi comunque pianificare il fallimento.

La mia idea è che, poiché un alto grado di rischio è inevitabile, vai direttamente verso un piano per il fallimento. Cerca di avere fallimenti piccoli, rapidi e ben definiti in modo da poter iterare, anziché dire che faremo tutto bene la prima volta, che è un pensiero illusorio. Poi, intraprendi un percorso che potrebbe durare probabilmente sette anni, per perdere infine mezzo miliardo di euro nel processo. Questo è il tipo di pensiero illusorio sulla gestione dei progetti.

Kieran Chandler: Fantastico, mi piace. Il consiglio di Lokad del giorno: se stai per fallire, fallisci rapidamente. Geniale. Quindi è tutto per questa settimana. Torneremo la prossima settimana con un altro episodio. Fino ad allora, grazie per aver guardato.