00:00:07 Incolpare i dati errati nei progetti di supply chain.
00:00:33 Perché i dati errati sono una scusa facile per il fallimento del progetto.
00:01:42 Sfide con i dati errati e fraintendimenti sulla loro qualità.
00:03:16 Difficoltà nell’accesso ai dati dai sistemi ERP e sfide con i fornitori.
00:06:32 Problemi che sorgono durante la migrazione tra sistemi ERP e corruzione dei dati.
00:08:01 Affrontare gli inserimenti di dati errati e il loro impatto sui sistemi ERP.
00:09:48 Previsione e individuazione di problemi nei dati storici.
00:11:37 Come l’evoluzione della semantica e i cambiamenti di definizione possono portare a problemi di dati.
00:12:20 Problemi di scalabilità e ottimizzazione del recupero dei dati man mano che le aziende crescono.
00:14:45 Sfide nella creazione di estrazioni giornaliere pulite e potenziale per errori nei dati.
00:16:02 L’impatto dei tempi di elaborazione più lunghi sulla risoluzione dei problemi nei reparti IT.
00:17:15 La questione della semantica dei dati e dei fraintendimenti nell’interpretazione dei dati.
00:19:22 L’importanza della documentazione per ogni campo dati per garantire una corretta comprensione.
00:21:01 Il ruolo dei professionisti della supply chain e del reparto IT nella comprensione della semantica dei dati.
00:23:59 La gamma di problemi sotto l’ombrello dei dati errati e l’identificazione delle cause principali.
Riassunto
In questa intervista, Kieran Chandler e Joannes Vermorel discutono il ruolo dei dati nell’ottimizzazione della supply chain e le sfide affrontate dai fornitori di software e dai professionisti del settore. Vermorel sottolinea che il problema principale non sono i “dati errati”, ma piuttosto l’accesso e l’utilizzo efficace dei dati. Le sfide includono sistemi obsoleti, documentazione inadeguata e responsabilità per l’accesso ai dati. Conflitti di interesse con gli integratori, problemi di migrazione del sistema, previsione e scalabilità rappresentano anche dei problemi. Per ottimizzare la gestione della supply chain, le aziende devono comprendere e affrontare i problemi legati ai dati, investire in una documentazione adeguata, chiarire la semantica dei dati e mantenere aspettative realistiche, anziché incolpare i dati per i fallimenti.
Riassunto Esteso
In questa intervista, Kieran Chandler e Joannes Vermorel, fondatore di Lokad, discutono il ruolo dei dati nei progetti di ottimizzazione della supply chain e le sfide affrontate dai fornitori di software e dai professionisti del settore. Iniziano affrontando l’idea che i “dati errati” vengano spesso usati come capro espiatorio per il fallimento dei progetti di supply chain. Vermorel fa notare che incolpare i dati è un modo comodo per evitare di incolpare le persone che potrebbero prendersela personalmente e reagire. Tuttavia, sottolinea anche che comprendere la causa principale di un problema è cruciale.
Vermorel afferma che i problemi legati ai dati sono probabilmente la causa principale di fallimento dei progetti di ottimizzazione della supply chain, ma la percezione dei “dati errati” è spesso fuorviante. Sostiene che la maggior parte delle aziende occidentali ha avuto dati accurati per decenni, grazie all’uso di codici a barre, lettori di codici a barre e altre tecnologie. Il vero problema, secondo Vermorel, non è la qualità dei dati stessi, ma piuttosto le sfide nell’accesso e nell’utilizzo di essi.
Una delle sfide chiave nell’utilizzo efficace dei dati è ottenere l’accesso ad essi. Molte aziende utilizzano da anni vari sistemi di pianificazione delle risorse aziendali (ERP), sistemi di gestione magazzino (WMS), sistemi di gestione del trasporto (TMS) e altre soluzioni software, ma questi sistemi possono essere difficili da utilizzare quando si tratta di esportare i dati. Vermorel identifica alcuni scenari in cui l’accesso ai dati può essere particolarmente problematico:
1 Sistemi obsoleti: Alcune aziende utilizzano ancora sistemi vecchi di 40 anni, con backend obsoleti e proprietari che rendono estremamente difficile l’estrazione dei dati. 2 Mancanza di documentazione: I fornitori di software potrebbero non fornire una documentazione adeguata per i loro sistemi, rendendo difficile comprendere e navigare tra le numerose tabelle e campi presenti nei database. 3 Responsabilità e accesso: Determinare chi è responsabile di concedere l’accesso ai dati può essere una sfida, in quanto coinvolge più stakeholder all’interno di un’azienda, tra cui il fornitore di software, il dipartimento IT e i professionisti della supply chain.
L’intervista sottolinea l’importanza di comprendere e affrontare le sfide legate ai dati nei progetti di ottimizzazione della supply chain. Sebbene la qualità dei dati stessi non sia tipicamente il problema, le difficoltà nell’accedere e utilizzare i dati possono contribuire al fallimento di questi progetti. Identificare e affrontare le cause principali di queste sfide è essenziale per garantire il successo delle iniziative di ottimizzazione della supply chain.
Approfondiscono le problematiche legate ai dati che possono sorgere dalle relazioni con i fornitori, dalle integrazioni di sistema e dalla scalabilità delle aziende.
Una delle questioni chiave che discutono è il potenziale conflitto di interessi con gli integratori, che potrebbero essere più interessati a vendere le proprie soluzioni di ottimizzazione della supply chain anziché collaborare con il fornitore scelto dall’azienda. Ciò può portare a situazioni in cui le aziende vengono tenute in ostaggio dagli integratori, rendendo difficile accedere o utilizzare i dati in modo efficace.
Un’altra sfida si presenta durante la migrazione da un sistema di pianificazione delle risorse aziendali (ERP) a un altro, il che può portare a una scarsa qualità dei dati o a una “integrazione errata”. Sebbene le singole voci di dati possano essere accurate, il processo di migrazione dei dati storici tra i sistemi può introdurre errori, poiché spesso non esiste una corrispondenza diretta uno a uno tra i dati nei vecchi e nei nuovi sistemi. Ciò può portare a corruzione dei dati, che potrebbe non avere un impatto significativo sulle operazioni quotidiane, ma può riemergere come un problema durante i progetti di ottimizzazione della supply chain o di analisi dei dati.
L’intervista affronta anche la previsione basata sui dati storici, che può essere difficile a causa dell’incertezza intrinseca del futuro. Individuare problemi all’interno dei dati storici è più facile quando i problemi sono visibili, come lacune o cambiamenti improvvisi nei dati. Tuttavia, i cambiamenti sottili nella semantica o nelle definizioni nel tempo possono portare a problemi più difficili da individuare, soprattutto durante la migrazione tra sistemi.
Con la crescita delle aziende, la scalabilità può anche introdurre problemi legati ai dati. Per le piccole aziende, l’intero set di dati storici può spesso essere contenuto in uno smartphone, rendendo l’ottimizzazione meno preoccupante. Tuttavia, man mano che le aziende crescono, il volume stesso dei dati può diventare un problema. La discussione sottolinea l’importanza di comprendere e affrontare questi problemi legati ai dati al fine di ottimizzare efficacemente la gestione della supply chain.
Vermorel spiega che le aziende spesso faticano ad estrarre i dati dai loro sistemi di pianificazione delle risorse aziendali (ERP), poiché questi sistemi non sono progettati per fornire incrementi giornalieri puliti dei dati. Ciò comporta processi complessi, che possono portare a un’estrazione errata dei dati e all’introduzione di bug. Il debug e la risoluzione di questi problemi possono richiedere molto tempo, settimane anziché ore, a causa della quantità di dati coinvolti e dei tempi di elaborazione lenti.
Molte aziende credono di avere dati validi, ma in realtà la semantica dei dati spesso è poco chiara. Ciò può portare a fraintendimenti e calcoli fuorvianti. Ad esempio, una “data dell’ordine” può avere più interpretazioni, come il momento in cui l’ordine è stato effettuato dal cliente, il momento in cui è stato registrato nel sistema o il momento in cui il pagamento è stato confermato. Per evitare fraintendimenti, Vermorel suggerisce che le aziende dovrebbero avere una documentazione dettagliata per ogni campo e tabella nei loro sistemi di dati, riflettendo la complessità della loro supply chain.
Un problema comune nell’ottimizzazione della supply chain è che i professionisti potrebbero non dedicare abbastanza tempo a qualificare i loro dati, il che porta i fornitori a lavorare con informazioni incomplete o poco chiare. Ciò può portare a una situazione di “spazzatura dentro, spazzatura fuori”, in cui i dati non sono necessariamente errati ma sono fraintesi a causa di una documentazione scadente.
Per affrontare questi problemi, Vermorel sottolinea l’importanza di identificare la causa principale del problema, che di solito coinvolge persone e strutture organizzative. Le aziende dovrebbero capire chi è responsabile del fallimento e lavorare per risolvere i problemi sottostanti, anziché limitarsi a incolpare i dati. I fornitori dovrebbero anche essere onesti riguardo alle sfide e al tempo necessario per chiarire la semantica dei dati, anziché essere eccessivamente ottimisti al fine di chiudere accordi.
Le aziende devono investire in una documentazione adeguata, una semantica dei dati chiara e aspettative realistiche per ottimizzare la loro supply chain e prevenire fallimenti derivanti da problemi di dati.
Trascrizione completa
Kieran Chandler: Oggi su Lokad TV, cercheremo di capire perché questa è una diagnosi così imprecisa e capire anche quali possono essere alcune delle sfide legate ai dati che possono essere incontrate sia dai fornitori di software che dai professionisti della supply chain. Quindi Joannes, perché i dati errati sono una scusa così facile?
Joannes Vermorel: Prima di tutto, perché i dati non possono lamentarsi. Nessuno li difenderà, quindi stai incolpando qualcosa di inerte, il che è meglio che incolpare un collega che lo prenderà personalmente e reagirà. Ma la realtà è che quando si arriva alla causa principale, sono sempre le persone a essere responsabili del problema. Incolpare i dati significa saltare il passaggio di identificare la causa principale del problema.
Kieran Chandler: È sicuramente facile prendersela con qualcosa che non reagirà. Quindi come possiamo essere più precisi? Quali sono alcune delle sfide?
Joannes Vermorel: I problemi legati ai dati sono probabilmente la causa principale dei fallimenti nei progetti di ottimizzazione della supply chain. Ma ci sono alcune idee sbagliate. Quando le persone parlano di “dati errati”, intendono numeri corrotti o incorretti. Tuttavia, per la maggior parte delle aziende occidentali, hanno avuto dati molto accurati per decenni. Quasi nessuno inserisce numeri di parti errati o fa errori di battitura. Utilizzano codici a barre, lettori di codici a barre e altri trucchi come RFID. Quindi la quantità di dati veramente errati è di solito una frazione molto piccola e non è sufficiente a spiegare perché la maggior parte delle iniziative che falliscono a causa di problemi legati ai dati effettivamente falliscono.
Kieran Chandler: Se la grande maggioranza delle aziende occidentali sta raccogliendo dati abbastanza buoni, quali sono alcune delle sfide che possiamo incontrare che ci fanno pensare che i dati non siano così buoni?
Joannes Vermorel: Il primo problema è ottenere l’accesso ai dati. Saresti sorpreso. Le aziende hanno utilizzato varie versioni di ERP, WMS, TMS o altri software aziendali per gestire e operare le loro aziende quotidianamente per decenni. Ma la maggior parte di questi sistemi non è molto user-friendly quando si tratta di esportare i dati. In alcuni casi, hai sistemi così antichi che non hai nemmeno un database SQL relazionale adeguato a supporto del sistema. In questo tipo di situazione, è davvero difficile estrarre i dati perché il backend è tipicamente completamente obsoleto e proprietario.
Kieran Chandler: Quindi chi si occupa di farlo?
Joannes Vermorel: Qui ci sono molte responsabilità. Innanzitutto, puoi avere il fornitore del software che non ha fornito alcuna documentazione significativa sul sistema. Nei casi peggiori, apri il tuo database e ti rendi conto che il tuo ERP contiene 2.000 tabelle, ognuna con da 20 a 200 campi, ed è un incubo. È completamente enorme e non sai da dove cominciare. Anche se sai dove cercare, puoi avere un problema con il fornitore, poi puoi avere un problema con l’integratore. Il problema con l’integratore è che potresti avere un conflitto di interessi. Alcuni integratori potrebbero avere un vivo interesse nel venderti la loro ricetta per l’ottimizzazione della supply chain, per questo modulo o per quell’altro modulo o qualcosa del genere. E quando chiedi loro di fare una estrazione dei dati per te, per i tuoi team interni o per qualsiasi altra iniziativa che vuoi portare avanti con un altro fornitore, l’integratore può essere - succede, l’abbiamo visto fare molte volte - semplicemente non collaborativo. Perché, ancora una volta, per loro è solo nell’interesse strategico essere non competitivi. E qui hai una situazione di ostaggio in cui l’azienda è presa - è di fatto presa in ostaggio dall’integratore. L’azienda, l’azienda informatica responsabile della configurazione, a volte dell’hosting e in generale, sai, della manutenzione dell’ERP o di altri sistemi informatici dell’azienda. Quindi questo è un altro tipo di problema di dati. Ma vedi, ha molto poco a che fare con i dati.
Kieran Chandler: Sì, sicuramente. Non essere in grado di accedere ai propri dati sembra un ostacolo piuttosto grande. E quali sono alcune delle altre sfide che possono verificarsi? E un grande mal di testa che molti dei nostri clienti hanno è quando migrano da un sistema ERP a un altro sistema ERP. Cosa può fare ciò ai dati?
Joannes Vermorel: Non può causare problemi. Quindi questa è la situazione in cui si può avere un altro tipo di dati errati. Ma qui, è davvero il dato che è sbagliato quando si ha una integrazione errata. Quindi dico che tipicamente le voci dei dati sono corrette, ma quando si passa da un ERP a un altro, ciò che può fare il fornitore o l’integratore o il dipartimento IT interno è cercare di migrare i dati storici dal vecchio sistema al nuovo sistema. Il problema è che non hai una corrispondenza uno a uno tra, sai, ciò che era una vendita ricevuta nel vecchio sistema e ciò che è una vendita ricevuta nel nuovo sistema. Forse le cose sono organizzate in modo diverso, quindi non c’è un modo chiaro per riportare i conti da ricevere dal vecchio sistema al nuovo sistema. E alla fine ti ritrovi con integrazioni provvisorie e dove può portare a corruzione dei dati, è che se, direi, fai una reimmissione impropria della tua storia, non impedirà alla tua azienda di operare giorno per giorno. Vedi, se l’Est Oracle è importato in modo errato nel nuovo sistema, per la maggior parte delle operazioni quotidiane non avrà alcun impatto. E anche se ha un impatto, di solito qualcuno farà semplicemente una correzione rapida per qualcosa che è sbagliato e procederà. Quindi potrebbe essere una fonte di attrito continuo, ma prima di tutto, sta scomparendo rapidamente perché se le persone inciampano, ad esempio, diciamo che hai codici fornitore che sono stati importati in modo errato. Voglio dire, le tue possibilità sono che non hai un milione di fornitori, quindi i tuoi fornitori più frequenti, i tuoi 100 fornitori più frequenti probabilmente verranno corretti in termini di correzione delle voci di dati errate entro due settimane dalla data in cui inizi a utilizzare il nuovo sistema. E forse, sai, tre mesi dopo, hai praticamente corretto ogni singola voce di fornitore errata. Ma il problema è che il codice storico, le persone non torneranno indietro e correggeranno, sai, i dati storici. Quindi diciamo che avevi cinque anni di storia, forse tre
Kieran Chandler: In futuro, quanto è facile individuare questi problemi che potrebbero essere accaduti in passato?
Joannes Vermorel: È facile individuare questi problemi quando ci sono problemi evidenti, come dati mancanti per alcuni mesi. Tuttavia, possono esserci cambiamenti sottili più difficili da individuare, come differenze nel modo in cui vengono conteggiate le vendite, se sono inclusi frodi o resi. Ciò può portare a molti problemi difficili da individuare nei dati storici perché la stessa definizione dei dati che stai guardando è cambiata nel tempo, e non è ovvio a meno che non ci sia un picco o un’impennata evidente.
Kieran Chandler: Un altro problema comune tra i clienti con cui parliamo è la scalabilità. Man mano che un’azienda cresce, i suoi dati diventano più disordinati. Quali sono i problemi che la scalabilità può introdurre?
Joannes Vermorel: Quando non hai problemi di scalabilità, puoi semplicemente copiare tutti i dati dell’azienda ogni singolo giorno. Per le piccole aziende, questo potrebbe essere gestibile poiché l’intera loro storia potrebbe essere inferiore a 10 gigabyte. Tuttavia, man mano che cresci fino a diventare aziende più grandi, ti ritrovi con molti più dati e devi passare al recupero incrementale dei dati. Ciò significa estrarre una porzione dei dati ogni giorno e alcuni sistemi non sono progettati per gestire ciò in modo efficiente o accurato. Quindi, devi fare cose complicate per creare un’estrazione giornaliera pulita e nel processo ti esponi a potenziali problemi.
Kieran Chandler: Quindi, alla fine, ti ritrovi con dati errati solo perché vuoi fare l’estrazione dei dati in modo incrementale ed è complicato perché il sistema potrebbe non essere stato progettato per questo compito. Quando pensi al debug, vuoi solo copiare i dati da un luogo all’altro e può essere un problema molto banale. Se il processo richiede un minuto, qualcuno nel tuo dipartimento IT può dedicare cinque minuti, avviare il processo e essere sicuro che funzioni. Tuttavia, se il processo richiede sei ore per essere completato, diventa un processo più tedioso. Puoi spiegare le sfide in questa situazione?
Joannes Vermorel: Certamente. Immagina di avere un sistema in cui il processo richiede sei ore per essere completato. Nel tuo dipartimento IT, qualcuno avvierà il processo, aspetterà 10 minuti, si renderà conto che sta impiegando troppo tempo e farà qualcos’altro. Potrebbe persino dimenticarsene. Il giorno successivo, potrebbe notare un piccolo bug che ha causato un crash dopo sei ore. Per riprodurre il problema, ci vorranno altre sei ore di ritardo. Di conseguenza, ti ritrovi con problemi che potrebbero essere risolvibili in poche ore, ma a causa della maggiore complessità e dei tempi di elaborazione più lunghi, si trasformano in un processo molto tedioso in cui i ritardi totali diventano settimane. Non perché richiedono settimane di sforzo, ma perché le persone avviano il processo, se ne dimenticano e tornano il giorno successivo. Questo porta a iterazioni molto lente.
Kieran Chandler: Quanto diffusi diresti che sono questi problemi? Ci sono molte aziende là fuori che credono effettivamente di avere dati molto buoni, ma in realtà, quando li guardi sotto la superficie, non sono così fantastici?
Joannes Vermorel: Sì, c’è un altro problema di cui non abbiamo discusso, che è la semantica stessa. Molte aziende credono di avere dati buoni, ma in realtà i dati hanno una semantica sconosciuta. Quello che intendo è che, ad esempio, quando parliamo di una data di ordine, ci sono molte interpretazioni possibili. Potrebbe essere la data di ordine del cliente, l’ora in cui l’ordine è stato effettuato sul sito web, registrato nel sistema o persino quando il pagamento è stato confermato come valido. Potrebbero esserci 20 diverse interpretazioni di cosa significhi questa data di ordine.
Quando iniziamo a lavorare con i clienti, di solito ci troviamo di fronte a tabelle e colonne con poca documentazione. Ma quando abbiamo finito di preparare i dati, abbiamo quasi una pagina di documentazione per campo per tabella. Una situazione tipica della supply chain ha circa 20 tabelle con 20 campi, quindi stiamo parlando di 400 pagine di documentazione solo per chiarire cosa significa il dato. Le persone di solito sono molto sorprese di questo, ma è necessario comprendere correttamente i dati.
Kieran Chandler: Joannes, puoi parlare dell’importanza di comprendere correttamente i dati nell’ottimizzazione della supply chain?
Joannes Vermorel: Sì, è proprio la complessità della tua supply chain che si riflette in questi dati e se non fai questo lavoro, ti ritrovi con dati che non comprendi correttamente. Quindi, è spazzatura in entrata, spazzatura in uscita. Non che i dati siano spazzatura, nel senso che i numeri sono sbagliati, ma non sai cosa significano i dati. Quindi, se hai una data che non comprendi correttamente, qualsiasi calcolo o modernizzazione che farai, finirà per essere fuorviante. Quindi, la semantica dei dati è la conclusione chiave e la documentazione deve essere in atto prima di poter iniziare un progetto.
Kieran Chandler: Quindi, chi è responsabile per quanto riguarda la semantica?
Joannes Vermorel: Direi che dovrebbero essere i professionisti della supply chain a essere responsabili. La maggior parte di loro direbbe che è un problema dell’IT. Ma, come vedi la semantica dei dati dipende davvero dal processo che hai. Se hai il processo in cui stai scansionando i prodotti all’ingresso del magazzino perché hai questo processo, estrai intorno al dipartimento IT. Non sono sul campo nel magazzino, quindi non sanno esattamente come è impostato il tuo processo. Le uniche persone che sanno esattamente perché questi dati sono solo il risultato di un processo che genera, sono in primo luogo nel sistema. Quindi, il mio punto è che non aspettarti che l’IT, che si occupa solo della gestione delle macchine, si assicuri che il software abbia abbastanza memoria di calcolo, larghezza di banda del disco, abbia le intuizioni, le competenze e la comprensione per capire cosa significano i dati. Quello che i dati significano è tipicamente un problema molto specifico del business. Non è affatto un problema dell’IT. Quindi, tipicamente, la colpa spesso ricade anche sul lato dei professionisti. I professionisti non hanno dedicato abbastanza tempo per qualificarlo correttamente con le loro parole e la loro comprensione. Pertanto, quando c’è questa ottimizzazione della supply chain, ti ritrovi con un fornitore che finisce per trattare questi dati a metà cieco. Ciò porta a spazzatura in entrata, spazzatura in uscita.
Kieran Chandler: Quindi, anche il fornitore può essere responsabile?
Joannes Vermorel: Sì, ovviamente, anche il fornitore può essere responsabile. Aziende come Coke Ad che stanno ottimizzando la supply chain, e di solito quando il fornitore è colpevole, è perché il fornitore sta cercando di essere furbo. Di solito, stanno cercando di minimizzare la loro sfida perché stanno cercando di vendere un problema. Stanno discutendo modi come “Fidati di noi. Sarà un gioco da ragazzi. Lo faremo in poche settimane. Boom, lo faremo così e funzionerà.” La realtà è che se dici a un direttore della supply chain: “Temo che solo per qualificare i tuoi dati ci vorranno sei mesi e mi dispiace, avresti dovuto farlo tu, ma non l’hai fatto, quindi dovremo farlo noi”, ovviamente è difficile chiudere questo tipo di accordo. Quindi, è molto più facile essere eccessivamente ottimisti, ma poi è una ricetta per il fallimento. Quindi il fornitore deve prendersi la colpa perché dovrebbero saperlo meglio. Forse il cliente non lo sa meglio perché è la prima volta che cercano di fare un progetto di ottimizzazione quantitativa predittiva della supply chain. Ma poi il fornitore, che per definizione, probabilmente non è la loro prima volta, lo stanno facendo. Dovrebbero saperlo meglio. Quindi, se la situazione diagnostica in cui questo tipo di dati è inesistente, allora dovrebbero
Kieran Chandler: Allora, dovrebbero avvertire semplicemente il cliente che dovranno forse dedicare mesi di sforzo solo per chiarire la semantica dei dati in modo che i dati possano essere qualificati come buoni. Ma non era che fossero davvero cattivi all’inizio. Quindi, buono non è l’opposto di cattivo in questa situazione; è solo che buono è più simile all’opposto di dati oscuri o dati non qualificati o dati disordinati.
Joannes Vermorel: Ok, e per concludere oggi, ci sono una vasta gamma di problemi diversi che rientrano effettivamente in quella categoria di dati cattivi. Direi di cercare di identificare la causa principale del problema e di solito sono le persone. Voglio dire, ovviamente, quando dico che sono le persone, non voglio incolpare James del dipartimento IT per essere responsabile del disastro. Ma quando dico che il problema sono le persone, devi capire esattamente chi è il responsabile del fallimento e forse questa persona è stata messa in una situazione in cui non poteva fare altro che fallire.
Vedi, puoi arrivare alla conclusione che James del dipartimento IT ha fallito, ma anche che l’organizzazione stessa ha messo questo povero James in una posizione in cui non aveva altra opzione se non fallire realisticamente parlando. Quindi, è interessante che inizi a vedere il problema da un angolo che almeno ti dà indizi su come risolverlo anziché dire che i dati erano cattivi, troppo cattivi, dati cattivi. E poi, se dovessi fare un’altra iniziativa, ripeteresti lo stesso identico problema, gli stessi identici errori e quindi finiresti con lo stesso fallimento alla fine della giornata.
Kieran Chandler: Ok, beh, se il capo di James sta guardando, spero che sia comprensivo. Ad ogni modo, questo è tutto per questa settimana. Grazie mille per averci seguito e ci vediamo la prossima volta. Ciao per ora.
